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Chapter  I:   Introduction 

One  of  the  fastest  growing  disciplines  in  computer  science  is  in  the 
area  of  data  base  management.  Since  information  is  such  a  uital  part  in 
all  aspects  of  our  Hues,  the  management  of  the  information,  especially 
in  business,  becomes  an  euen  greater  concern.  The  ability  to  retrieue 
the  necessary  data  needed  to  solue  uarious  complexities  of  problems  is 
absolutely  essential  in  order  to  suruiue  in  today's  world.  Data  base 
management  systems  (DBMS'*)  are  software  packages  that  prouide 
users  ways. to  effectiuely  and  hopefully  efficiently  manage  their  data  in 
order  to  prouide  answers  to  queries  to  the  system. 

There  are  three' main  types  of  logical  models  for  databases  used  in 
data  base  management  systems.  They  are  hierarchical,  network  and 
relational,  a  common  one  used  for  personal  computers.  Each  type  of 
database  has  aduantages  and  disaduantages  so  the  model  used  depends 
largely  on  the  application.  The  logical  model  used  to  design  a  database 
is  usually  either  hierarchical,  network  or  relational.  The  first  two  are 
better  suited  for  accesses  from  multiple  files  to  answer  a  query  while 
the  relational  model  prouides  greater  efficiency  when  extracting  the 
data  from  one  file  at  a  time  in  answering  a  query.  In  this  study,  the 
popular  DBMS  marketed  by  Rshton-Tate,  dBase  li  will  be  studied  within 
the  context  of  a  particular  application.  Seueral  logical  database  designs 


for  the  same  application  will  be  Implemented  in  dBase  II  to  eualuate 
the  design. 

The  use  of  data  base  management  systems  offers  seueral  important 
aduantages.  The  data  has  the  property  of  relatibillty  meaning  that  by 
the  data  being  related  or  compatible,  more  information  can  be 
obtained  from  existing  data.  This  decreases  the  cost  and  time  needed 
to  deuelop  new  systems.  One  of  the  DBMS's  goal  is  to  eliminate  data 
redundancy  which  leads  to  higher  data  integrity.  Without  this,  data 
might  haue  to  be  changed  in  seueral  locations  in  order  to  prouide 
nonconflicting  reports.  Because  of  data  generally  being  in  a  central 
location  In  a  DBMS,  ease  of  availability  Is  provided  along  with  a  greater 
control  of  security.  It  is  easier  to  modify  data  since  you  generally  only 
haue  to  go  to  one  place  instead  of  many.  Recess  to  the  data  base  can 
be  limited  to  only  essential  personnel  and  one  can  prouide  access 
restrictions  on  certain  files  or  fields  within  the  database.  Another 
aduantage  to  DBMS's  is  that  of  program/data  independence. 
Programmers  do  not  haue  to  concern  themselues  with  the  manner  in 
which  data  are  stored  in  the  database.  Modification  of  a  data  structure 
can  be  made  without  hauing  to  change  the  application  program. 

Data  base  management  systems  as  useful  as  they  are,  are  not 
without  disaduantages.  Large  systems  can  be  rather  eHpensiue,  costing 
In  the  hundreds  of  thousands  of  dollars.  DBMS's  tend  to  be  more 
complex  than  single  application  systems  so  the  high  cost  is  partially  a 
reflection  of  the  more  aduanced  programming  techniques  used  in  the 
design. 


Large  Interactive  DBMS's  utilize  much  main  memory,  placing  a  high 
demand  for  on-line  storage.  Backup  and  recouery  is  more  difficult  due 
to  the  complex  nature  of  a  DBMS  and  the  concurrent  way  that  database 
processing  Is  done. 

RELATIONAL  MODEL 

The  relational  database  model  Is  probably  the  easiest  of  the  three 
main  models  for  users  to  understand.  Relations  are  set  up  in  two 
dimensional  tables  having  rows  and  columns.  Each  rout  (also  called 
tuple),  can  be  viewed  as  a  record  within  the  relation  and  each  column 
as  attributes.  Each  distinct  attribute  within  a  record  is  called  a  field.  R 
relation  or  file  then  consists  of  records  with  each  record  having  one  or 
more  fields.  No  two  records  con  be  the  same  in  a  relation.  The 
attribute  or  attributes  that  uniquely  Identifies  a  tuple  is  called  a 
candidate  key  with  the  primary  key  designated  as  a  unique  identifier 
from  among  the  candidate  keys. 

The  dBase  II  system,  a  relational  database  designed  for  use  on 
personal  computers,  allows  up  to  a  maximum  of  65,535 
records/database  file  with  as  many  as  1000  characters/record.  They 
can  only  have  a  maximum  of  32  fields/records  and  no  field  may  contain 
more  than  254  characters.  DBase  II  has  been  commercially  available 
since  1901  and  has  been  one  of  the  most  popular  DBMS's  used  In  the 
business  world  ever  since. 

Reading  database  literature  provides  one  with  quite  a  diversity  of 
Information.  Much  work  has  been  done  In  comparing  different  DBMS's 
products  similar  to  dBase  II.    Products  such  as  Selector  U,  FMS-80, 
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Condor  III  along  with  dBase  II  are  put  through  bench  mark  tests  to 
compare  the  four  basic  types  of  databases  functions  -  input,  Selection 
and  Sorting,  Processing,  and  Report  generation.  Speed  and  efficiency  is 
measured  to  determine  which  product  is  best  suited  for  the  users 
particular  needs. 

Many  journal  articles  are  deuoted  to  studying  the  different  query 
languages  and  deueloping  new  ones  in  order  to  make  it  easier  for  the 
user  to  access  the  data.  The  query  language  Is  referred  to  as  the  data 
manipulation  language  (DML)  and  describes  the  necessary  techniques 
used  In  processing  the  database.  Ideally,  the  DML  should  be 
independent  of  any  programming  language.  Another  important  concept 
for  the  DML  is  to  allow  the  user  to  deal  in  logical  or  symbolic  terms 
rather  than  physical  addresses.  This  allows  application  programs  to  be 
written  without  concern  for  data  structures. 

The  data  definition  language  (DDL)  is  a  non-procedural  language  that 
describes  the  database.  It  specifies  the  name  and  type  of  each  field, 
the  way  the  fields  are  grouped  Into  records,  and  indicates  keys.  The 
DDL  Is  used  to  describe  the  schema  that  represents  the  overall  logical 
structure  of  the  database. 

Within  the  uast  literature,  uery  little  Information  can  be  found  on  the 
comparison  of  different  schemas  for  the  same  application  using  the 
same  database  management  system.  This  is  a  prime  reason  for  this 
research  work. 

The  problem  that  Is  Investigated  will  be  the  comparison  of  seuen 
different  schemas  for  one  application  using  dBase  II  as  the  database 


management  system.  Emphasis  Is  placed  on  the  ouerall  efficiency  of 
the  schemas  to  determine  which  ones  are  best  suited  for  online  type 
applications  and  which  ones  for  batch  related  queries.  Efficiency  is 
measured  by  two  items,  the  lines  of  code  necessary  for  each 
application  program  written  for  each  of  the  seuen  schemas,  and  the 
time  required  to  execute  the  indiuldual  application  programs.  From 
these  determinations  it  will  prouide  some  guidance  to  database 
designers  to  predict  the  tgpe  of  schema  needed  for  a  particular  kind  of 
application  with  these  efficiency  needs. 

The  schemas  used  in  this  study  were  designed  by  students  from  the 
graduate  database  management  class  at  Kansas  State  Unluerslty.  The 
students  were  all  employees  of  Western  Electric  with  an  aboue  average 
work  experience  In  computer  science  and  its  related  fields.  Each  set  of 
three  to  flue  students  were  responsible  for  designing  a  separate 
schema  and  Implementing  It  using  dBase  II.  The  same  application 
enuironment  was  given  to  each  set  of  students.  The  schemas  used 
were  not  modified  except  where  needed  In  order  for  my  application 
programs  to  be  implemented. 

Following,  will  be  a  brief  summary  of  the  contents  in  this  paper: 
Chapter  one  Is  the  introduction.  Specific  terms  relating  to  databases 
and  database  management  systems  haue  been  mentioned.  Advantages 
and  disadvantages  of  DBMS  s  are  discussed  along  with  the  three  main 
tgpes  of  database  models.  The  relational  model  Is  given  closer 
attention  because  the  relational  DBMS,  dBase  II,  will  be  used 
throughout   the  paper.      The   problem   is   presented   with   a   brief 


explanation  to  how  the  answer  will  be  resolved.   Possible  conclusions 
drawn  from  the  results  obtained  are  also  briefly  discussed. 

Chapter  two  is  the  detailed  discussion  of  the  application 
enuironment.  The  schemas  were  all  designed  based  upon  the  needs  of  a 
pseudo  Insurance  company.  The  specific  documents  essential  for  the 
gathering  of  data  for  the  Insurance  company  are  discussed.  The 
functions  required  for  the  ongoing  daily  business  of  the  insurance 
company  are  proulded  as  well  as  the  functions  that  were  selected  for 
comparison  of  the  schemas.  Specifics  on  the  data  used  in 
Implementation  Is  given.  The  hardware  enuironment  is  also  discussed. 

Chapter  three  Includes  detailed  descriptions  of  the  seven  different 
schemas.  Entity  relationship  diagrams  will  accompany  each  schema. 
The  schema  will  be  implemented  using  dBase  II  therefore  the 
descriptions  will  Include  information  on  the  fields  within  a  record  and 
how  each  attribute  is  defined. 

Chapter  four  couers  the  details  of  implementation  and  problems  that 
occured.  Any  modifications  to  the  original  schemas  required  for 
implementation  are  discussed. 

Chapter  five  is  the  key  section  of  this  paper.  In  it,  the  main  analysis 
of  the  schemas  Is  done  based  on  the  results  of  the  comparisons. 
Individual  schemas  will  be  compared  to  one  another  on  the  basis  of  the 
number  of  lines  of  code  that  are  essential  for  the  implementation  of 
two  separate  applications  and  the  execution  time  of  each.  Both 
applications  will  be  discussed  In  detail.  One  will  be  chosen  to  display 
on-line  (interactive)  characteristics  of  a  database  and  the  other  to 


show  batch  related  processing.   Recommendations  for  using  a  certain 
type  of  schema  with  a  particular  application  will  be  determined. 

Chapter  sIh  summarizes  the  final  results  obtained  from  this 
research.  Comments  are  also  made  on  the  general  performance  of 
dBase  II  with  mention  of  Its  posltlue  qualities  as  well  as  its  limitations. 
Possible  areas  of  future  research  are  touched  upon. 

Little  is  known  about  the  efficiency  of  code  used  in  relational 
database  management  systems  such  as  dBase  II.  The  research  done  for 
this  paper  will  prouide  a  better  comprehension  as  to  the  effect  a 
schema  design  has  on  the  efficiency  of  relational  database  processing. 


Chapter  2:   Application  Environment 

The  seuen  schema*  used  in  this  study  were  all  designed  for  one 
application  environment.  They  resulted  from  different  perspectiues  the 
design  groups  took  during  the  project.  Specifics  inuolued  with  data 
used  in  implementation  are  discussed  as  uiell  as  the  specific  functions 
that  were  chosen  to  compare  the  different  schemas. 

The  application  enuironment  centers  around  the  functions  and 
requirements  of  a  pseudo-insurance  company.  The  agency  has  one 
general  agent  whose  primary  responsibility  is  to  all  the  uarious 
insurance  and  investment  companies  for  which  the  agency  sells 
products.  There  are  two  subagents  who  answer  directly  to  the  general 
agent  and  an  office  manager  who  manages  the  office  staff. 

fln  insurance  company  generally  sells  more  than  one  line  of  product 
in  order  to  offer  a  well  balanced  portfolio  to  its  prospectiue  clients. 
This  agency  sells  products  for  three  insurance  companies,  annuities  for 
two  companies  and  Individual  Retirement  Recounts  (IRR's)  for  three 
companies.  The  agency  must  be  able  to  enpand  because  occasionally 
more  companies  will  be  added.  The  agency  must  be  able  to  eitpand  to 
offer  different  types  of  products  such  as  securities. 

Each  agent  is  licensed  to  sell  a  type  of  product.  R  commission  is 
acquired  for  each  product  sold  but  is  dependent  of  the  type  of  product 
and  the  company  offering  it.    Commissions  to  agents  are  always  a 


percentage  of  the  client  payment.  Ouerride  commissions  are  paid  to  the 
general  agent  on  all  products  sold  by  the  agency.  The  ouerride 
commission  Is  determined  by  the  product  and  the  company  and  is 
eHpressed  as  a  percentage  of  the  client  payment. 

In  order  to  gather  all  the  data  the  agency  needs,  seuen  documents 
ore  used.  These  are  as  follows;  I)  a  client  file  card  (figure  2.1),  2)  the 
insurance  application  (figure  2.2),  3)  client  asset  sheet  (figure  2.3),  4) 
estate  settlement  worksheet  (figure  2.4),  5)  cash  flow  statement 
(figure  2.5),  6)  pro  forma  cash  flow  statement  (figure  2.6),  7)  statement 
of  financial  position  (figure  2.7),  and  policy  record  (figure  2.8). 

The  client  file  card  is  one  of  the  documents  most  used  by  the  agent. 
It  forms  an  easy  access  file  for  the  agent  and  is  used  to  respond  to 
phone  requests  by  the  client  and  for  information  to  meet  most  all  of  the 
dally  reminder  euents. 

The  life  insurance  form  is  filled  out  and  sent  to  the  home  office 
wheneuer  insurance  is  requested,  fl  copy  of  the  form  is  kept  in  the 
clients  folder.  Most  of  the  data  on  the  Insurance  form  is  unnecessary 
for  continuous  Interaction  with  the  client.  The  most  important  data  is 
the  type  and  amount  of  insurance  and  the  specific  information  found  on 
the  policy  record. 

The  client  asset  sheet  is  used  as  an  Important  data  collection 
document.  The  data  is  used  by  the  agents  to  prepare  a  financial 
analysis  on  each  client.  This  document  is  stored  with  the  client  file  and 
should  be  updated  annually. 


The  estate  settlement  work  sheet  is  created  for  each  spouse  as  a 
complimentary  serulce  to  Its  clients.  The  financial  analysis  Is  prouided 
for  both  husband  and  wife  where  appropriate. 

The  cash  flow  statement  is  giuen  to  each  client  as  a  helpful  aid  to 
determine  the  amount  of  money  that  they  can  use  on  inuestments  and 
Insurance.  This  document  and  the  pro  forma  cash  flow  statement  are 
filled  out  by  the  client. 

To  prouide  a  detailed  financial  analysis,  the  statement  of  financial 
position  is  filled  out  by  the  client  to  be  used  by  the  agent. 

The  policy  record  sheet  is  a  document  that  is  often  referenced  by  the 
agency  because  It  contains  Information  on  all  the  policies  that  the  client 
has  in  force.  This  information  is  used  to  assist  the  agent  in  preparing 
the  annual  reuiew.  Cash  ualue  on  policies  change  annually  which  must 
be  reflected  In  the  policy  record  sheet. 

Reports  are  vital  for  an  insurance  agency  to  continue  to  eulst 
profitably.  Seueral  reports  are  needed  by  this  agency  with  the  purpose 
for  each  one  giuen. 

The  daily  contact  report  is  a  reminder  system  that  informs  the 
agents  and  secretaries  of  euents  that  will  occur  such  as  appointments 
and  specific  items  of  business  to  be  done  on  a  certain  day.  Reminder 
euents  such  as  annual  reuiews  for  clients,  policy  insurance  follow  up, 
client  courtesy  cards  (birthday  greetings),  and  premiums  to  be  paid. 
These  euents  can  be  added  to  the  daily  card  up  to  one  year  prior  to  the 
day  they  must  be  processed. 
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Most  euents  added  to  the  daily  contact  file  may  be  generated 
automatically.  Annual  reviews  should  be  scheduled  at  one  year 
Intervals  from  the  date  of  the  last  review.  R  reminder  to  schedule  the 
annual  review  appointment  should  be  inserted  one  week  before  a  year 
has  elapsed  since  the  last  review.  Most  of  the  client  courtesy  cards  are 
birthday  cards.  R  reminder  should  be  inserted  into  the  file  at  least 
three  working  days  prior  to  the  actual  birthday. 

Client  follow  up  for  Insurance  can  also  be  scheduled  automatically. 
The  procedure  begins  when  an  application  form  is  recieved  by  the  office 
manager  from  the  home  office  of  the  insurance  company.  The  secretary 
should  be  reminded  to  call  the  home  office  of  the  insurance  company 
after  five  working  days  has  elapsed  to  see  If  the  doctor's  follow  up  to 
the  application  form  has  been  received.  If  it  has  then  no  additional 
reminder  is  necessary.  The  secretary  should  call  the  doctor's  office 
immediately  if  the  follow  up  has  not  been  received.  If  the  doctor's 
office  says  they  have  sent  the  form  then  the  secretary  should  be 
reminded  In  two  days  to  call  the  home  office.  All  calls  are  recorded  in 
the  client's  record  for  the  agent's  information. 

Another  automated  function  is  the  reinstatement  follow  up  for 
Insurance.  This  process  Is  initiated  when  a  client  falls  to  pay  a  premium 
on  time.  The  agent  should  be  notified  of  this  on  the  next  day's  daily 
reminder.  If  the  client  intends  to  reinstate  the  policy  the  secretary 
should  be  given  a  reminder  In  two  weeks  to  check  with  the  home  office 
to  see  If  the  proper  forms  and  payment  have  been  received. 
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When  an  agent  sells  insurance  to  an  out  of  town  client,  the  secretary 
should  be  reminded  In  two  weeks  to  check  on  the  receipt  of  the 
application  by  the  agency. 

Replacement  follow  up  for  insurance  clients  is  another  procedure 
which  may  be  semi-automatlcally  done.  The  goal  is  to  minimize  the 
payment  for  the  client.  Two  weeks  after  the  replacement  policy  is  sold, 
the  secretary  should  be  reminded  to  contact  the  home  insurance  office 
to  see  If  the  policy  has  been  issued  so  the  client  may  be  immediately 
notified  to  stop  payment  on  the  replaced  contract. 

Prospect  letters  are  sent  daily  with  follow  ups  for  these  taking  place 
three  days  later  by  the  agents.  If  any  reminder  items  are  not 
accomplished,  they  are  to  be  automatically  scrolled  to  the  next  working 
day. 

Seueral  reports  are  required  for  management  purposes  to  report  the 
state  of  the  business,  fl  quarterly  and  annual  report  list  the  income  and 
eHpenses  to  the  agency.  Hn  entry  for  an  expense  giues  the  date, 
description,  amount  and  the  individual  to  whom  the  expense  is  to  be 
charged.  Income  entries  glue  the  date,  amount  and  the  name  of  the 
person  who  brought  the  money  into  the  agency.  Rll  commissions  are 
divided  by  the  companies  before  checks  are  sent  with  only  the  income 
to  the  general  agent  considered  as  income  to  the  agencg. 

The  annual  report  classifies  expenses  into  categories.  The  categories 
are  taxes,  office  supplies,  wages,  telephone,  rent,  transportation,  client 
entertainment     and     gifts,     education,     charitable     contributions, 
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professional  dues  and  insurance.   The  categories  are  assigned  bg  the 
secretaries  as  data  entered  Into  the  expense  files. 

fl  set  of  statistical  reports  are  generated  on  a  periodic  basis.  The 
reports  list  year  to  date  information  for  the  following  items:  Number  of 
insurance  sales  per  month,  number  of  other  sales  per  month,  dollars  of 
Insurance  coverage  sold  per  month,  dollars  of  premium  sold  per  month, 
dollars  of  commissions  sold  per  month,  dollars  of  other  products  sold 
per  month,  and  dollars  of  commissions  recelued  per  month. 

fill  the  schemes  were  implemented  using  the  Zenith  150  (2-150) 
personal  computer  euen  though  an  IBM  or  IBM  compatible  product 
would  work.  The  Z-150  has  an  8088  microprocessor  with  320K  of 
dynamic  RHM  with  dual  disk  drives  hauing  720K  bytes  capacity,  fl 
Zenith  composite  monochrome  uideo  monitor  was  used.  The  operating 
system  is  MS/DOS.  Double  sided,  double  density  soft  sectored  HIDEH  5 
1/4"  disks  were  used. 

To  implement  the  seuen  database  designs,  dBase  II  uersion  2.41  is 
used.  This  uersion  has  several  enhancements  as  compared  to  version 
2.40  of  which  several  will  be  mentioned  here.  One  of  the  most 
noticeable  Improvements  is  seen  using  the  INDEH  command.  It  no 
longer  takes  on  unusually  lony  time  to  index  when  using  commands 
such  as  APPEND,  EDIT,  and  REND. 

when  using  JOIN  in  previous  versions  one  could  not  JOIN  two  files 
together  with  matching  field  names  without  creating  duplicate  fields  in 
the  new  file.  If  the  new  file  exceeds  32  fields,  dBase  II  will  lock. 


13 


The  specifications  on  dBase  II  u2.4l  are  as  follows: 

Records/database    65,535  max.  Numeric  accuracy  10  digits 

Characters/record    1,000  maH.     Char,  string  length  254  chars.  maH. 

Fields/record            32  max.         Command  line  length  254  chars.  man. 

Characters/field       254  maH.       Report  header  length  254  chars,  man. 

Largest  number        1.8h10«        Index  key  length  100  chars.  maH. 

Smallest  number      1h10-«3          EHpressions  in  Sum  5  maH. 

command 

Rs  mentioned  previously,  the  2-150  was  used  in  implementiny  the 
database  designs,  however,  any  8080,  8085  or  Z-80  based 
microprocessor  system  or  an  8086  or  8088  system  with  CP/M-86  or 
MS/DOS  operating  system  could  be  used.  DBase  II  also  requires  at  least 
48K  bytes  of  memory  and  at  least  one  mass  storage  device. 

The  application  environment  chosen  for  comparing  the  designs 
involued  the  implementation  of  two  separate  programs  for  each  of  the 
seuen  designs.  The  first  program  compares  the  interactive 
characteristics  of  the  databases.  6lven  a  clients  name,  the  first 
program  will  produce  a  list  of  what  policies  the  client  has  and  which 
agent  sold  each  policy.  The  second  program  exemplifies  the  batch 
characteristics  of  the  schemes.  It  will  produce  a  report  on  a  monthly 
basis  that  tells  the  number  of  sales  per  month,  total  dollar  amount  of 
those  sales,  and  the  different  types  of  insurance  sold  for  each  agent. 
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NAME 

BI3THDAYS 

INSURANCE 

Month 

Dsy 

Y*a< 

R«3id«nc0 

PHONE 

OCCUPATION 

WIFE'S  NAME 

FIRM  ADDRESS 

PHONE 

CHILDREN 

REFERRED  BY 

PHONE 

Club.  Church,  Fr»t..  Hobb.es 

Aprjrox.  Income 
* 

BEST  TIME  TO  SEE:                        Da 
At    Work                                    n.y.;™ 
Ai  Moms                             ,  Evenir 

1 

fl 

CALL 
DATE 

NEED 

RESULTS 

CALL 
DATE 

NEED 

RESULTS 

OTHER  INFORMATrON 


PRESENT  LIFE  INSURANCE 

Oat* 

Plan 

Amoon, 

&*n-'(t 

e*n.r,c,afY 

Prsmium 

Comp»ny 

WP 

lot 

Dl 

Mod. 

Ami 

Oj. 

Client    File    Card 


FIGURE    2. 1 
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(Check  Company  desired) 


Part  1 


ini„,.nce  Company 
Lite  Assurance  Company 


PROPOSED 
NSURED 


10.  PLAN:  (Sta 
Baas: 


■.  using  language  ol  Rate  Book) 


Rider: 


D   Male         Q   Married  D   Widowed        D   Separated 

D   Female    D    Single  □   Divorced 


.  Slate  and 
Date  of 
Birth: 


.   Proposed  Insured's 
Social  Security  No, 


AGE: 

last  birthday 


ADDITIONAL  BENEFITS  (Chech  each  benefit  des.re 

U   Waiver  ol  Premium  □   GPO  $ 

H   Accidental   Dealh   I 

CI   Children's  flidet  S 

D   Spouse  Rider  $ 


G   Payor  Benelit 


lie   Pre 


is  contained   i 


.  ADDRESS  for  Premium  Notices: 

Street,  Number  . 

City 

ZIP 

c/o  (II  needed) 


POLICYOWNER  to  be: 

D   Proposed  Insured 
D  Other 


Name  ol  Owner 

Relationship  to  Proposed  Insured 

Social  Security  or  Tax  I.D.  No. 

Contingent  Owner  (if  any) 

(Name  and  Reialionshlo  to  Prooosed  Insured) 


Ownership  shall  be:     (il  Proposed  Insured  is  Age  0  thru  t4) 
D    Until    the    Insured    attains    the    age    of    21.    the    owner    shall 
Owner  named  above,  while  living,  otherwise  Ihe  Contingent  Owi 
living,  otherwise  the  InsuieB  Ownership  Shall  automatically  translei 


D  Permanent  In  the  Owner  w 


iving.  then  Ihe  Contingent  Owner 


-.ach  owner,  during  tn.s  period  of  ownership,  shall  have  the  power  to  ex- 
irclse  all  Ihe  existing  policy  rights  Ol  an  owner,  including  the  right  to 
liter  the  succession  of  owners  and  their  interests  A  "conimgent 
■wW  is  Ihe  person  designated  to  succeed  to  the  rights  of  the  o.vner 
hould  (he  owner  die  during  the  Insured's  lifetime.  It  there  is  no  Con- 
ingenl  Owner,  ihe  Owner  s  rights  upon  his  dealh  may  Be  exercised  by 
■is  executors,  administrator  or  assigns 


Will  any  existing  tile  or  annuity  contracts  be  lapsed,  surrendered,  ot 
borrowed  against,  or  changed  il  Ihe  proposed  policy  is  issued,  or  has 
Ihere  been  any  such  change?  (II  "Yes",  furnish-  lull  name  of  issuing 
c°'"P*"y' □   Yes         D   No 


.  ANNUITIES: 

O   Flex  Prem  Annuiiy  al  Retirement  Age_ 
n   Single  Premium  Oelerred 


.   DIVIDEND  OPTION  (Complele  only  on  Participating  f  an 
D   Paid  Up  Additions  Q   Accumulated  at  Interest 

□   Paid  In  Cash  O   Reduce  Premiums 


D  PAC        O  GA 


LIFE  INSURANCE  &  ANNUITIES  IN  FORCE: 

Company  Amount 


BENEFICIARY:  Print  lull  giv 


Age         Relationship 


U   Lawful  children  of  the  Insured  (including  any  named  above 
.!   Children  born  ol  or  legally  adopted  to  the  marriage  of  th' 
Insured  and  primary  beneliciary  (including  any  na^ed  above 
Check  only  if  spouse  ol  Insured  is  named  as  Beneficiary. 


n  proposed  lor  ir 


iGiveOETAHS 


OCCUPATION: 


ne^ngo'co^terr 

wlT*' L" 

•nsuta 

CI="Ow 

I : 

" 

c  wZZZ'T, 

nTa^iP  III 

»  llighl 

amolete  A,  Page  2} 

i  ■ 

G 

Names  of  Others  to  be 
Insured  (Spouse,  Childre 


OTHER  PEhSONS  PROPOSED  FOR  INSURANC E 


Proposed  Insured 


tome  Oflice  Corrections  or  Additions:  (Do  not  wrili 
"NOT  (or  use  in  Pa.,  Md..  and  WV 


.   Additional  Information  and  Special  Requests 
Whenever  more  space  is  needed  in  tins  application,  use  a  separate 
page  identified  by  application  number  and  signed  by  applicant  and 
Proposed  Insured. 


Insurance   Application 
FIGURE    2.2 
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HIS  QUESTIONNAIRE  IS  COMPLETED  WITH  RESPECT  TO:  (Prlnl  lull  name|_ 


•ART  A  —  AVIATION  ACTIVITIES  -  COMPLETE  IF  NO.  17c.  Page 
.  Indicate  your  current,  past  or  intended  Hying  status: 
D   Pilol         D   Student  Pilot         U   Crew  member  or  observer 

!.  ANSWERED  YES. 

9    Eileni  ot  past  or  anticipated  Hying  by  type  ol  Hying  indicated  in 
Question  8. 

Hours  ol  Flying  Time 

1.   Do  you  My  in  any  military  or  military  reservo  capacity  or 
Intend  to  do  so?         □   Yes         O   No 
If  so,  state  capacity: 

Type  ol  Flying 

Last  12  Mo 

1   to  2  Y'S    Ago 

Ncxl  12  Mo 

.  Daleol  last  (light? 

.  Types  oi  certificates  he'd  and  issue  dales? 

Military  Pilot  or  Crew 

i-  Do  you  have  an  Instrument  Flying  Rating' 
C)   Yes         (J   No 

10.   Principal  types  ol  aircialt  down' 

'.  Have  you  ever  been  in  an  aUcrall  accident  or  been  grounded 
lor  violation  of  regulations'         G   Yes         D   No 

11.  Should  aviation  coverage  be  issued  lor  eitra  premium. 
11  required'                            Q   Y„         fJ   Uq 

11  "Yes",  eiplam  in  Remarks 

12,    REMARKS: 

.  Types  01  Hying  you  do  or  intend  to  do 
D   Pleasure,  personal  business          7     Scheduled  airline 
G   Nonscheduied  carrier          Q   Business  planes 
D  Charter         r   Flight  Instruction         L   Test-production 
□   Test-experimental         Li   Dusling.  seeding,  spraying 
G   Olher: 

'ART  B  — HAZARDOUS  SPORTS  OR  HOBBIES-   COMPLETE  IF  NO.  17d.  Page  1  ANSWERED  YES 

I  .  Underwaler  Diving 
i-      Type  Of  diving? 

LI  Skin      [j   Scuba      G  Olher 

b.  Do  you  dive  commercially  or  intend  to 
II  "yes",  give  details: 

c.  Number  ol  dives  in  past  12  momns?_ 

d.  Number  of  dives  anticipated  in  next  i; 

e.  Usual  depth  ot  dive ft.  Mai 


:   Pa. 


Type  ol  jumps  made? 

Toial  number  of  jumps? 

Number  ol  jumps  fast  12  montns'. 
Number  ol  lumps  anticipated  next 


t2  montfis'_ 
Are  you  a  member  ol  a  parachute  club?  LJ  Yes 
II  "Yes",  give  name 


.  Hang  Gliding 

a.  How  frequently  do  you  hang  glide' 

b.  Are  you  a  member  of  an  organized  club' 

c.  How  high  do  you  usually  fly' 

d.  What  is  the  greatest  neigni 

duration down' 


U   Drag 

Other 


.  Auto  or  Motorcycle  Racing 
a.      Type  Of  auto  racing'      C   Stockcar 

I  i    Championship      |~     SpoMscar      ' 
b       Type  ol  motorcycle  racing'      7'    Hill  climbing 

CI   Championship      "_   Scramblers      '      Other 

c.      Type  ol  course'     P   Track  l!   Drag  strip  Road 

C '   Olhet  

d       Do  you  drive  professionally  or  intend  to?      G    Yes  'J    Ni 

e.      Number  of  'aces  last  12  months? 

I       Number  of  n 

g.     Speeds  attained' 

h.      Racing  organisation' 
Engine  Make 


ices  anticipated  ne«l  i2monlhs?_ 


What  type  of  fuel  is  used'_ 
Class 


«HI  U  -  MILIIARY  STATUS  -  COMPLETE  IF  NO.  17e.  Page  1  ANSWERED  YES 

I.  Are  you  m  the  Armed  Forces,  National  Guard  or  any  Hese've  Unit' 
G   Yes         I !   No 
11  "Yes",  complete  the  following: 

3.   Have  you  volunteered  lor  (or  intend  to),  or  loceived  orders  lo<.  or  nave 
reason  lo  believe  thai  you  will  be  assigned  to  hazardous  overseas 
duty'            '   Yes         t  ■   No 
If  "Yes",  give  details  in  Remarks. 

C.      Job  classifications 

*     REMARKS: 

I    Current  address  it  different  from  lace  Ol  application. 

• 

FIGURE 


(CCr'T.  ) 
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Hon  ol  Ihe  AddIic; 
ONS  19-27 


MUST  BE  COMPLETED  IN  ALL  CASES 


Joes  any  person  proposed  tor  insurance  now  have,  or  has 

le  ever  had: 

a)  Tuberculosis,  asthma,  disease  ol  lungs  or  respiratory 

Chest  pain,  Hear!  murmur. 
■  lory  system' 


(e)  Disease   ot   the   urinary   sysiem   including   nephritis, 
Kidney    stone,   disease   ol    the   kidneys,   bladder,   or 

prostate1 


(f|    Sugar,  albumin,  or  blood  in  the  u 


Lseaseol  muscles, 


t  or  disorder  ol  Ihe  eyes,  ears,  nose  ( 


In  the  past  5  years  has  any  person  proposed  for  insurance, 
(a)  Had  or  been  advised  to  have  a  surgical  operation1 
[•ray,  blood  sludy,  o'  other 

(c)  Been     a     patient     in    any    hospital,     instilulion,     or 

Has  any  person  proposed  tor  insurance  ever: 

(a)  Applied  'or.  or  received  pension  or  ijsapility  benelils'' 

(b)  Been  teiected  lor  or  received  a  medical  discharge  from 
Military  Service? 

{c)  Sought  advice  or  treatment  lor  or  been  arrested  lor 
the  use  or  possession  ol  any  narcotic,  stimulant. 

sedalive.  or  hallucinogenic  drug1 

td)  Had  advice  or  treatment  ipj  use  ol  alcohol1 
(el  Had  any  parents,   brothers  or   sisiers  who  had  heart 
disease,  diabetes,  stroke  or  high  blood  pressure' 

now   under    any 


D  D 

a  g 


D  D 
D   □ 


g  a 

□  D 


p  a 

D  D 


g_g 
a  d 


D  □ 


TTTT 

g  n 


g  d 


|,  How  much  time  has  the  proposed  insured  tost  Irom  work         Q  None 
during  the  last  two  years  because  of  rllness  or  injuries'' Weeks 


Proposed  Insured 
Height  (In  shoes) 


Were) 

hi  one  yea 

ago 

[fcxp 

unanydil 

eren 

over 

0  lbs  J 

YES, "  give  due  dale  . 


p  g 

D  G 


27.    FAMILY  RECORD  - 


Brothers 

and 
Sisters 


application.  (3)  EXCEPT  AS  STATED  IN  I 

ALLOTMENT  CONDITIONAL  rNSURANI 

RELATING  TO  THE  PROPOSED  INSURANCE  AND  DELIVERED  10  THE  APHUCAl 

UNTIL.  OURING  THE  CONTINUED  INSURABILITY  OF  THE  PROPOSED  INSURED.  A 

DELIVERED  TO  THE  APPLICANT  AND  THE  FULL  r-IRST  PflEMIUM  IS  PAID:  jnj  1. 1 

»  Horn*  OM.ce  Co.rrc.oni  or  Aad.l.om  e.ceci  »r>ar«  .„i,an  jtcjpunce  or  noni 


;  SAME  POINTED  HUM»t"Aj  I  HIS  APPLICATION,  A  DULY  EIECUTEDGOY 
ER  AS  IHIS  APPLICATION.  01  A  CONDITIONAL  SA1AR*  DFDUCHON  AC 

GRANTS  NO  INSURANCE  UNfJEB  THIS  Am>CA  HON  L   ILESS  AND 
:S  PROPOSED  FOR  INSURANCE  HEREIN.  A  POLICT  ISSUED  ON  THIS  APPLICATION  >S 


s 

(Musi  Always  Be  AnsweieO) 

has  been  paid  to  the  agent  n 
and  until  all  terms  and  condi 

mod  below   Thts  payment  can  in  no  way  bind  Ihe  Company  unless 
ions  ot  the  corresponding  conditional  receipt  below  are  met. 

S.rjncrj 

„ 

10837 

1  HAVE  READ  THE  COMPLETE  APPLICATION  BEFORE  SIGNING. 

Signature  ol  Proposed  Insured  HI  o.nr  age  1*1 

Signal 

Winn 

re  ol  Policyowner  il  ome'  tlian  Proposed  insured  Inamed  in  No   51 

Sign.iluic  u'  Prcp'jiffl  insu'ed  SDOu'.e  (.1  included  under  SIhj 

Signaiu'e 

o.  Agon. 

Signature  ol  Po'>Cfn*nt-F  anunj.  Payor  iJuvrn.it-  Poiicr  or.iyi 

FIGURE    2.2     (CONT. ) 
18 


AUfcNISHtPORT 

ft]  (This  infotmation  must  be  completed  with  EVERY  application) 

t.  Was  Inspection  or  Telecom  ordered? Oate. *.,„,,  r    k      r- 

"■"•i Attach  Ca'bon  Copic 


2.  Residence  Address  ol  Proposed  Insured: 

Sireel   and  No 

II  Rural:  Lives miles  in  a 

3.  Former  Address  (lasl   3  years) 

*    Employer   and   Arldress   


.  Cily  and  State 


Ho*"-"  i) 


5.  Maiden  name  ol  any  woman  lo  be  insured  it  marriage 

6.  How  much  insurance  does  spouse  have?  J 


0     EXAMINATION  ARRANGEMENTS  BY 


1.  Is  a  medical  examir 

2.  ON 


3.   Name  ol  Doclc 


i.   Is  he  one  of  our  approved  examiners? 
5.  II  rules  lequire,  did  you  arrange  lor 

Second  Medical  exam? 

EKG? 

Chest  X  ray? 

Sending  specimen  to  Home  Oll.ce  Reference  Lab' 

SMA-12  Blood  Test? 


a  u 


IJ)]      1.   How  long  have  you  known  Proposed  Insured  (Aopiic 
Insured  i«  under  age  15p 
ted' 


D  D 


D  D 

D  D 

D  D 

D  D 

D  G 

a  n 


C]      Will  any  existing  life  or  annuity  contracts  be  lapsed,   surrendered, 
borrowed  against,  or  changed  it  the  proposed  policy  is  issued? 
I     No 

[■   Yes    -    Complete    comparison/disclosure    statemenl    required    bv 
stale  of  application 


2.  Are  you  aware  olanythtngaboulthe  health,  habits  lobbies  pwiron 
JJJJB  m„0,  „,  ,„.  .„„,  m,o„,  ,„«,  „,„„,„,,„„  „,  p,„osM 

t"    Yes  No 

3.  Whal  .s  the  source  ol  income  (other  than  income  from  occupa-nnp 


is  be  paid  from  personal  funds? 

e  ot  Proposed  Insured  s  annual  income 


gj      IP  PROPOSED  INSURED  IS  UNDER  AGE  15: 

1  Did  you  see  the  child  proposed  lor  insurance7 

2  Does  the  child  appear  in  good  healih? 


sisters  has  the  child? 


stslers  insured7 


6.   Amount  of  insurance  in  force  on  supporting 

parents'    S ^___ 

*    Remarks _^____ 


TO  BE  COMPLETED  IF  INSURANCE  IS  FOR  BUSINESS  PURPOSES  OR  FOR  ESTATE  CONSERVATION 
Business  Insurance  Estale  Conservation 

1.  Value  o.  Business  $ Proposed  Insured's  tnleresl V.       5.  Approximate  Value  of  G-OSs  Estate* 

2.  Proposed  Insured's  Compensation:  Salary  J Bonus  S Olher  $ 

3.  Purpose  ol  Insurance.  6_  Type  o|"  Business 
D   Key  Person                             a  Spill  Dollar 
□    Fund  Buy  and  Sell                   Q   Executive  Bonus 
D   Delerred  Compensation        G   Estale  llquidily 


D   Sole  Proprielorshio  P    Partnership 

D  Corporation  Stale  ol  Corporation 

...„ M    „,.„„,„,,„  7_  Name  olOllicerS.gmnt;  lor  Corporation  

*.   Names  o(  Other  Stockholders.  Officers  and  Parlners  and  Agent  ol  Business  Insurance  Carried  on  The,r  Uvea 


I  any  nol  insured,  give  explanation 

Gj     Details  to  any  of  above  questions  (slate  q 


SOURCE  OF1  '   'Policyowner 
PROSPECT  [     2  Referred  leai 


.  3  Cold  Canv; 
1  *  Direc!  Mail 


'  5  Policyowner  Spry 
:.    6  Of  her 


Credit  this  application  to_ 
(fl-splilcredil) 

THIS  HEPORT 
MUST  BE  SIGNED 


.    Code  No  _ 
_  Code  No ._ 


ANNUAL  PREMIUM  CALCULATION 


FIGURE    2.2.     (CONT. ) 
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/ 

Name: 

. n.-itr*   nf  births 

Children i                                 _  . 

a.»tf   nf  Pirelli 

/ 

n*t-r>  nr  births 

! Data  nf  hir(-h: 

ASSETS 

His            Hers 
Market  Value  of  Home                 s             . 

5             5 

Other  Real  Estate 

Joint 

Indebt. 
$ 

Personal  Property 

Checking  Account                                                              

Savings  Account 

CD. 's.  Money  Market 

Stock,  Securities 

Life  Insurance 

Life  Insurance 

Life  Insurance                                                              ■ — 

Retirement  Plan  Death  Benefit 

OTHER  INFORMATION 

Husband's  Salary: 

Income  need  in  the  event  of  a  premature  death: 

Would  you  want  an  education  fund: 

Inheritance  potential: 

OBJECTIVES 

Client   Asset   Sheet 
FIGURE  2.3 
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E iti ma (•  of  Cash  Ne«ded  to  Settle  Your  Estate 


Estate  Settlement 
Worksheet 

1.   Grojj  Estate 

Z  Leu  Debts.  Outstanding  Taxes,  etc. 

3.  Ltu  Probate  end  Administration  Com 

4.  Adjutted  Gross  Estate 

5.  Leu  Marital  Deduction  (bl 

6.  Less  Charitable  Contributions  (c) 

7.  Taxable  Estate  . 
"8.  Tentative  Federal  Estate  Tax 

9.  Leu  Federal  Tex  Credit  (d) 

10.  Approximate  Federal  Estate  Tax  (•) 

11.  Total  Cash  Required  (0 
(a)   The  marital  deduction  does  not  apply  if  there  is  no  surviving  spouse 

let   The  estate  must  have  sufficient  funds  to  make  the  bequest 

"'  H'w"'^171™""  '983:  S96J<""°r  ,9M:  1"'-8«"»  »»*  S'SS.800f„  IHS.-dJ.gj.sOO 

(e)  Including  maximum  credit  for  state  inheritance  taxes.   The  state  taxes  n 
state  taxes  may  exceed  this  estimate. 

(f)  Sum  of  lines  2,  3  and  10. 


W.'h  Full 

M«i'il  D*duciion   <al 

Without 
Mvrtal  Deduction 

xxxxxxxxxx 

s  may  exceed  this  credit  so  the  total  federel  and 


Federal  Estate  Tax 


Taxable 
Cstate 

Eiuia 
Tax 

*  Tax  In 
naxi  Bracket 

Probauttlo 

t      10,000 

S        M00 

20ft 

30.000 

3.800 

33 

8,100 

34 

13.000 

PS 

'8.200 

2S 

33.800 

10 

150.000 

38.800 

33 

70.800 

34 

500.000 

155.800 

37 

348.300 

39 

345.800 

41 

4*8,300 

43 

555.800 

3.000.000 

1385 

3,500.000 

1,035.800 

Not  icgticiotn  to  o'c 

198* 

3.000.000 

1.390.800 

by  Contrtct   to  t   nam 

3.500.000 

1.575.800 

1982 

4,000.000 

1.880.800 

65 

by  termi  of  rrta  rruir 

Upper  limits  of  estate  tax  brackets  will  be  reduced  in  years  1982-1985.  Do  not  refer 
The  tax  brackets  in  parentheses  will  become  effective  when  the  year  inde 
estate  of  S3.600.000  w.11  be  in  a  61%  marg.naltax  bracket.    In  1983.  the 
bracket.  In  1 985.  a  taxable  estate  of  this  siie  or  any  taxable  estate 
bracket  of  50%. 


Average  Probate  and  Administration  Costs 
lor.  propariv  P*s.,ng  una*  in.  mil  <*  by  trie  laws  of  intestacy! 


S  3.500 
3,500 

5.S0O 
9.750 
14.500 
19.500 
25,000 
30.000 
35.000 
40.000 
45.000 
SO.OOO 


brackets  below  the  current  year, 
eached.    For  example,  in  1982  a  taxable 
i«  taxable  estate  will  be  in  a  60%  marg.nal 
excess  of  S2.500.000  will  be  in  a  maximum  tax 


Comoiew  i  h.  ramm  iMi  to  inow  Eitati  Sat  Ifefitam  c 


i  if  iht  or dw  ol  dtatn  is  reversed. 


FIGURE    2.4 
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Cash  Flow  Statement 
For  the  Year  Ending  


Cash  Balance  at  Beginning  of  the  Year 

INFLOWS 
Salaries  alter  taxes 

Dividends  in  cash 

Interest  received 

TOTAL    INFLOWS 


OUTFLOWS 

Savings  and  Investment 

Fixed  Outflows 

Mortgage  note  payments 

Automobile  note  payments 

Insurance  premiums 

Total  Fixed  Outflows 

Variable  Outflows 
Food 

Transportation 

Utilities /household  exp. 

Clothes  and  personal  care 

Recreation  and  vacations 

Medical  and  dental  care 

Taxes 

Miscellaneous 

Total  Variable  Outflows 


TOTAL  OUTFLOWS 

Cash  Balance   at  End  of   the  Year 


Cash  Flow  Statement 


FIGURE  2.5 
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Pro  Forma  Cash  Flow  Statement 
For   the  Quarter   Ending  


Cash  balance  at  beginning  of  month 
INFLOWS 

Salaries  after  taxes 
Dividends  in  cash 
Interest  income 
Borrowed  Funds 


TOTAL    INFLOWS 

OUTFLOWS 

Savings  and  Investments 

Fixed  Outflows 

Mortgage  note  payment 

Automobile  note  payment 

Insurance  premiums 

Variable  Outflows 
Food 

Transportation 

Household  Expenses  (inc.  util.) 

Clothes /personal  care 

Recreation  and  vacations 

Medical  and  dental  care 

Credit  card  payments 

Miscellaneous 


TOTAL  OUTFLOWS  $  $ 


$ 


SET  CASH   POSITION  $  5  - 

Additional   funds   needed 

Zash  Balance  at  End  of  Month  $  $  $ 


Pro  Forma  Cash  Flow  Statement 


FIGURE  2.6 
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Statement  of  Financial  Position 
As  of 


ASSETS 

Cash   and  Cash  Equivalents 
Cash  and  checking  account 
All-savers  Certificate 
Money  Market  Fund 


Total   Cash/Cash  Equiv. 
Invested  Assets 

Stocks  and  bonds 

Life  insurance  cash  value 

Vested  portion  of  pension 


Total  Invested  Assets 
Use  Assets 

Residence 
Automobiles 
Household  furnishings 
Clothing,    jewelry,  etc. 


Total   Use  Assets 
TOTAL   ASSETS 


LIABILITIES    AND    MET   WORTH 
Liabilities 

Credit  card  balance 
Automobile  note  bal. 


—         Mortgage  note  bal. 


Total  Liabilities 
Net  Worth 


TOTAL   LIABILITIES 
AND  NET   WORTH 


Statement  of  Financial  Position 


FIGURE  2.7 
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Policy  Record 
FIGURE  2.8 
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Chapter  5:  Logical  Database  Designs 

In  this  chapter,  each  of  the  seuen  different  database  designs 
created  by  the  student  programming  groups  is  examined.  The  design 
process  consists  of  two  steps  a)  Creation  of  the  entity-relationship 
diagram  and  b)  Determining  the  relational  schema.  Oiscussion  of  each 
entity-relationship  diagram  is  prouided  including  a  general  eualuation 
of  each  design  to  determine  ouerall  effectiveness  in  handling  the 
original  functional  specifications  (see  Chapter  Two).  Rfter  examining 
each  entity-relationship  diagram,  an  eualuation  is  done  on  the 
corresponding  relational  schemes.  Comparison  is  made  to  see  whether 
redesigns  of  the  systems  occured  between  the  formulation  of  the 
entity-relationship  diagrams  and  the  translation  of  them  into  relational 
schemas.  If  so,  justification  (or  the  probable  reasons)  of  overhauling  a 
particular  design  is  giuen. 

An  entity  when  used  in  the  context  of  databases  is  simply  something 
that  exists  and  can  be  distinguished  from  another  entity.  Entities  haue 
properties  which  are  called  attributes.  Each  attribute  may  take  a  ualue 
from  a  giuen  domain.  In  order  for  entities  to  be  distinguishable  from 
each  other,  there  must  be  something  to  uniquely  identify  them.  This 
unique  identifier  is  called  a  key  if  it  contains  no  extra  attributes,  fln 
entity  may  haue  more  than  one  key. 


26 


Relationships  emst  among  entity  sets  in  which  a  relationship  is 
simply  an  ordered  list  of  entity  sets.  There  are  seueral  classifications 
of  relationships  based  on  the  association  of  one  entity  set  to  another, 
fl  one-to-one  relationship  occurs  mhen  there  is  only  one  associated 
member  from  one  entity  set  to  another  (e.g.,  social  security  number 
identifies  at  most  one  person). 

R  many-to-one  relationship  eHists  between  entity  sets  in  which  one 
entity  in  set  E2  is  associated  with  zero  or  more  entities  in  set  Ej.  Each 
entity  in  set  E],  howeuer,  con  at  most  be  associated  with  only  one 
entity  in  E2  (e.g.,  a  father  and  his  children). 

R  relationship  where  no  restrictions  are  made  on  how  many  sets  of 
entities  can  enist  In  the  relationship  is  called  a  many-to-many 
relationship  (e.g.,  parts  and  assemblies  made  from  the  parts). 

fin  entity-relationship  (E-R)  diagram  is  a  tool  to  graphically 
represent  a  system  design.  Rectangles  represent  the  entity  sets  while 
attributes  are  represented  by  circles.  Diamonds  are  used  to  represent 
relationships  and  arcs  are  needed  to  link  the  different  entity  sets. 

The  relational  model  was  chosen  to  represent  the  Information  from 
the  seuen  different  E-R  diagrams.  To  represent  an  entitg  a  relation 
consists  of  all  the  attributes  of  the  entity  set.  R  relationship  between 
entity  sets  is  represented  by  0  relation  whose  schema  consists  of  the 
attributes  in  the  keys  of  the  entity  sets. 

In  eualuating  the  ouerall  effectiueness  of  each  design,  it  is 
important  to  reuiew  the  original  project  specifications  from  chapter 
two.  The  two  main  areas  of  concern  for  each  design  to  be  functional 
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are  the  reminder  system  and  that  of  the  uarious  reports  required  by  the 
ayency.  Each  desiyn  was  looked  at  to  determine  whether  these 
functions  could  be  fulfilled. 

Design  one  (see  figure  3.1)  has  thirteen  entities  with  twenty- three 
relationships.  The  entity  called  activity  is  a  bit  misleading  because  the 
attributes  include  activity  type    and  date  scheduled     With  all  the 
reminders  wanted  in  the  system  it  would  be  uery  difficult  if  not 
Impossible  to  anticipate  every  activity  required.    To  be  reminded  of 
birthdays,  it  would  be  best  to  start  with  client  and  migrate  from  there. 
It  would  be  advantageous  to  have  the  attributes  associated  with  family 
Infa    to  be  included  with  the  client  information  to  reduce  some 
overhead  in  maintaining  the  system  since  at  the  present,  one  has  to 
have  duplicate  Information  in  order  to  link  client   with  family  infa 
There  are  no  attributes  in  the  three  major  products  (insurance, 
annuities,  and  IRR's)  to  tell  whether  the  latest  premium  has  been  paid 
making  reinstatement  follow  up  for  insurance  clients  impossible  to  do. 
The  set  of  statistical  reports  can  be  adequately  provided  by  this  design. 
Design  two  (see  figure  3.2)  has  nine  entities  and  ten  relationships.  It 
is  noticeable  that  this  design  would  not  be  sufficient  to  handle  the 
requirements  laid  forth  in  the  functional  specifications.  This  schema  is 
only  able  to  manage  Insurance  products.  There  is  no  provision  for  IRfl's 
and  annuities  which  also  are  sold  by  the  ayency.  The  design  is  lacking  in 
the  statistical  reports  it  can  produce.  There  Is  no  field  within  the  entity 
policy  to  link  it  with  the  agent  that  sold  the  policy.    Because  of  this, 
one  could  not  produce  the  reports  dealing  with  commissions  sold  and 
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receiued  in  a  giuen  month.  Although  not  required  in  the  specifications, 
it  mould  be  helpful  to  haue  information  linking  agents  with  their  policy 
holders.  This  design  has  definite  limitations  in  this  area. 

Design  three  (see  figure  3.3)  has  seuenteen  entities  and  twenty 
three  relationships  and  will  perform  all  of  the  project  specifications.  It 
has  an  eHtenslue  reminder  system  and  would  be  able  to  produce  the 
required  statistical  reports.  Seueral  of  the  entities  like  hobbies  and 
occupational  Information  do  not  seem  to  haue  much  ualue  except  for 
additional  Information  that  one  might  want  to  know  on  a  particular 
client.  By  grouping  all  the  agency  employees,  clients,  children,  and 
spouses  under  the  same  entity  i.perso/1,  a  lot  of  memory  will  be  wasted 
storing  unnecessary  data. 

Design  four  (see  figure  3.4)  has  nine  entities  and  eight  relationships, 
it  Is  set  up  nicely  for  expansion  of  the  companies  product  lines.  The 
entity,  products  sold  by  agency,  allows  for  this  growth.  Depending  on 
the  type  of  product  a  client  owns,  there  may  be  some  unnecessary 
associated  attributes.  For  example,  it  is  doubtful  that  IRR's  would  haue 
riders  and  yearly  premiums.  The  entity  daily  reminder  which  is  related 
to  client  seems  to  be  properly  linked  for  effeciency  because  most 
reminders  are  generated  by  attributes  within  a  dint's  records.  The 
annual  income  and  expense  reports  as  well  as  the  statistical  reports 
can  be  produced  by  this  design. 

Design  flue  (see  figure  3.S)  has  seuen  entitles  and  seuen 
relationships.  The  system  will  expand  nicely  also  by  simply  adding  a 
new  type  to  the  products  entity.  The  reminder  system  would  possibly 
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be  more  efficient  if  it  was  linked  more  directly  to  the  client  entity,  fls 
it  stands  now,  one  has  to  migrate  through  agent  to  get  to  client  in 
order  to  arrive  at  data  within  client  that  is  needed  to  generate 
reminders.  It  would  be  uery  difficult  to  know  all  the  appointments  and 
annual  reulews  one  has  without  first  getting  the  information  from  a 
client's  policy  which  in  this  system  would  be  rather  ineffecient. 

The  ayency  financial  data  is  grouped  within  one  entity,  howeuer, 
without  date  fields  on  the  company  expenses  and  Incomes,  It  could 
cause  problems  when  preparing  a  quarterly  reports.  Because  of  the 
way  that  expenses  and  Income  are  grouped  within  the  same  entity, 
there  will  be  wasted  memory  In  inpiementatlon  using  a  relational 
database.  The  statistical  report  calling  for  the  dollars  of  premium  sold 
per  month  can  not  be  produced  because  there  is  not  a  premium 
attribute  within  the  policy  entity.  Most  all  of  the  other  reports  can  be 
produced  by  this  system. 

Design  six  (see  figure  3.6)  has  nine  entities  and  nine  relationchips. 
This  design  is  one  of  the  better  systems  when  looking  for  the  specifics 
in  commissions  percentages.  If  a  company  wants  to  chanye  the 
percentage  on  a  commission  for  a  giuen  product,  this  can  easily  be 
implemented  with  the  current  system  design.  The  quarterly  expense 
reports  can  easily  be  produced  by  this  system,  howeuer,  the  income 
reports  will  be  somewhat  more  difficult.  One  would  haue  to  determine 
all  the  policies  sold  within  a  set  period  of  time  and  depending  on  the 
type  of  product  sold  and  company  it  is  sold  for,  the  commissions  would 
haue  to  be  calculated  individually  then  summed  together. 
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The  reminder  system  would  seem  to  work  sufficiently  in  this  design. 
The  attribute  cl-results  makes  it  possible  to  record  the  results  of  a 
particular  need  so  that  one  can  again  be  reminded  on  a  subsequent  day 
if  necessary. 

Like  some  of  the  other  designs,  the  policy  entity  Is  centered  around 
insurance.  If  one  mere  to  haue  an  IRR  for  example,  there  would  be 
some  eHtra  unnecessary  attributes.  In  general  this  design  would  be 
able  to  produce  the  required  reports  with  little  ouerhead  in  migration. 

The  last  design  (see  figure  3.7)  has  ten  entities  and  ten  relationships. 
The  E-R  diagram  goes  into  a  lot  of  detail  although  there  are  seueral 
entities  that  could  probably  be  grouped  together.  The  general  agent 
and  sunagents  could  be  combined  since  they  haue  the  same  attributes. 
It  does  not  seem  to  be  necessary  to  haue  separate  entities  for  office 
manager  and  office  staff  with  relationships  joining  them  because 
there  is  not  any  useful  information  to  obtain  from  them.  Spouse  and 
Mid  could  also  be  combined  since  they  haue  the  same  attributes  and 
are  directly  related  to  client  The  entity  reports  does  not  seem  to  be 
seruing  any  useful  purpose.  Knowing  the  date  and  type  of  a  report 
does  not  In  itself  produce  worthwhile  information  without  hauing 
additional  data  to  build  the  report. 

The  entity,  product,  should  haue  a  date  field  on  it  and  possibly  be 
linked  to  client  This  design  would  assume  that  all  types  of  a  particular 
product  would  haue  the  same  price.  Rs  the  desiyn  stands,  It  is  probably 
the  least  able  to  allow  production  of  the  required  reports.  There  are  no 
basic  attributes  such  as  premium,  issue  date,  and  cashualue  on  a  client 
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policy  and  without  a  date  field,  monthly  reports  could  not  be  produced. 
The  quarterly  Income  and  eHpense  reports  can  not  be  produced  and 
there  is  no  evidence  of  a  reminder  system. 

In  reviewing  the  corresponding  relational  schemes  for  each  design, 
it  can  be  said  in  most  cases  that  there  Is  some  overhead  in  maintaining 
relational  model  databases.  In  order  to  traverse  through  the  schema, 
duplicate  attributes  must  be  maintained.  If  a  value  for  one  of  these 
attributes  ever  changes,  one  must  change  every  occurrence  of  this 
attribute,  a  drawback  in  maintaining  relational  databases. 

Comparing  the  relational  database  schema  to  its  corresponding  E-R 
diagram,  design  one  (see  figure  3.8)  is  very  close.  There  were  not  any 
major  changes  to  the  design  and  the  attributes  added  as  previously 
mentioned  were  for  migrational  purposes. 

Design  two  (see  figure  3.9)  in  the  relational  schemas  solves  a 
problem  mentioned  in  the  E-R  diagram.  There  is  the  agent  attribute  in 
policy  to  link  an  agent  with  a  policy  making  it  possible  to  produce  the 
commission  statistical  reports.  The  schema  is  still  lacking  in  that  if  a 
new  product  is  to  be  sold,  expansion  within  the  agency  is  limited. 

The  relational  schema  for  design  three  (see  figure  3.10)  ties  in  very 
closely  with  its  E-R  diagram.  Many  of  the  entities  have  name  as  the 
key  which  may  not  uniquely  identify  records  within  the  entity,  one  of 
the  problems  that  can  be  seen  with  this  schema. 

There  were  some  minor  changes  In  relational  schema  number  four 
(see  figure  3.11).  To  properly  link  the  daily  reminder  entity,  the  ciient 
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name  attribute  was  added.    The  remaining  schema  again  is  closely 
associated  with  its  E-R  diagram. 

Schema  number  flue  (see  figure  3.12)  contains  no  significant  changes 
from  its  E-R  diagram,  houieuer,  to  make  trauersing  through  the 
database  easier,  a  field  In  policy  should  be  added  to  link  a  policy  with  a 
client. 

Schema  sin  (see  figure  3.13)  and  its  related  E-R  diagram  are  closely 
associated  to  each  other  with  very  few  changes.  The  only  additional 
attributes  were  the  result  of  ones  needed  to  link  entities  together. 

Schema  design  seuen  (see  figure  3.14)  maintains  its  compatibility 
with  its  E-R  diagram,  howeuer,  there  were  some  entitles  added  to  the 
E-R  diagram.  R  major  change  In  the  design  of  the  system  would  be 
necessary  to  accomodate  the  reports  needed  for  the  agency. 

The  comparison  of  the  schemas  and  their  related  E-R  diagrams  are 
summarized  in  figure  3.15. 

In  the  newt  chapter  implementation  of  the  application  programs  is 
done  which  may  necessitate  modifications  to  the  current  E-R  diagrams. 
Rny  modifications  will  be  included  at  that  point. 
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RELATIONAL  DATABASE  MODEL 
0ESI6N  t 

RCTIUITV  (client-identifier,  employee-identifier,  keg:  activity-type, 
actiuity  date- scheduled) 

CLIENT  (client-name,  client-address,  client-phone-number,  client- 
occupation,  client-employer-address,  client-business-phone, 
client-referral-name,  client-income,  key:  client-identification) 

FflMILV-INFO  (client-identification,  insurance-amount,  family-relation, 
key:  name,  birthday) 

COMMISION-RflTE  (commission-rate,  key:  product-name) 

INSURRNCE-POLICY  (client-identification,  employee-identifier,  company- 
name,  insurance-amount,  insurance-type,  policy-issue-date, 
policy-premium,  wp-rider,  adb-rider,  yia-rider,  cpb-rider,  diuidend- 
option,  policy-loan-amount,  policy-loan-rate,  guaranteed-ualue, 
total-ualue,  primary-beneficiary,  contigent-beneficiary,  key: 
policy-number,) 

ANNUITIES  (client-identification,  employee-identifier,  company-name, 
annuity-issue  date,  annuity-amount,  product-name,  key: 
annuity-account-number) 

IRR  (client-identification,  employee-identifier,  company-name, 
ira-issue  date,  ira-amount,  product-name,  key:  ira  account 
number) 

EMPLOYEE  (employee-name,  employee-address,  job-title  key: 
employee-identifier) 

AGENT  (  key:  employee-identifier) 

INCOME  (commission-receiued,  company-name,  key:  commission 
received-date) 

COMPANY  (company-address,  key:  company-name) 

EXPENSES  (employee-identlfer,  expense-type,  expense-date,  expense- 
amount,  key:  enpenie  transaction  identification! 

SALES  (employee-identifier,  company-name,  product-name,  sales- 
amount,  commission-sold,  number-of-sales,  keg:  sales-date) 

COMPANY-AATE  (  key:  company-name,  product-name) 

CLIENT-AGENT  (keg:  employee  identifer.  client-identification) 

CLIENT- ACTIVITY  (key:  client-identifier,  actluity-date-scheduled, 
activity-type) 

EMPLOVEE-ACTIUITY  (key:  employee-identifier,  activity-date- 
scheduled,  activitg-tgpe) 

FIGURE  3.8 
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RELRTIONRL  DATABASE  MODEL 
DESI6N  2 

CHILD  (child-birthday,  total-amount-child,  key:  child-name,  client- 
name) 

TASK  (client-name,  event-type,  task-description,  results,  keg:  task-id, 
target-date,  target-person) 

CLIENT  (agent,  total-amount-spouse,  spouse-birthday,  spouse-name, 
client-birthday,  referred-by,  residence,  residence-phone, 
occupation,  firm-address,  firm-phone,  referred-phone, 
interest,  approH-income,  best-time-to-see,  owners-initial,  keg: 
client-name) 

POLICY  (agent,  client-name,  premium-due-date,  mode,  contingent- 
beneficiary,  primary-beneficiary,  cash-ualue,  loan-int-rate,  loan- 
amount,  loan,  dividend-option,  gross-yr-premium,  plan,  premium, 
apl,  riders,  age-of-insured,  date-of-issue,  face-amount,  ins- 
initial,  ins-name,  keg:  policy  number,  campang-name) 

COMPANY  (keg:  campang-name,  plan) 

AGENT  (agent-commission,  agent-type,  keg:  agent,  plan) 

INSUBANCE-PLAN  (company-name,  keg:  plan,  agent) 

EHPENSE-BECOAD  (agent,  eHpense-category,  eHpense-descrip,  eHpense- 
amount,  keg:  enpens e-date,  enpense-entrg-ne) 

INCOME-RECORD  (agent,  income-category,  income-descrip,  income- 
amount,  keg:  incnme-date,  incnme-entrg-nn) 

FIGURE  3.9 
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RELATIONAL  DATABASE  MODEL 
DESIGN  3 

PERSON  (address,  sen,  phone  bday,  bdaystate,  marital-status,  key: 

name,  ss#i 
0CCUPflTI0N_INF0  (hire_date,  occupation,  work_phone,  work_addr, 

emp_na,  key:  name) 
ASSETS  (amount,  key:  type,  name) 
OBJECTIVES  (key:  type,  name) 
LIABILITIES  (amount,  key:  type,  name) 
GA_C0MM_S0LD  (amt,  date,  keg:  name) 
COMPANV-INCOME  (income,  keg:  categarg,  date) 
COMPANV_EHPENDITURE  (description,  spender,  amt,  date,  keg: 

categnrg,  date) 
HOBBIES  (hobby_name,  keg:  name) 
APPOINTMENTS  ( keg:  name) 

CALENBBA  IcaLname,  caLtlme,  keg:  cal_date,  cal_topic) 
POLICY-RECORD  lco_name,  exp_date,  rep_date,  amt_of_ins,  date_sold, 

type,  diuidend_option,  loans,  primary_bin,  contingent_ben,  keg: 

palicg_nd) 
APS_F0AM  (aps_date,  aps_dr_name,  aps_date_recd,  key:  policy* i 
P0LICV_PREMIUM_INF0  (amount,  keg:  tgpe) 
NOTES  (keg:  name,  »s#) 
RGENCVJEMPLOVEE  (keg:  name,  «s#) 
KIDS  (keg:  name,  ss#l 
SPOUSE  (keg:  name,  ss#) 
REFERRED.BV  (keg:  name,  ss#) 
(PERSON)  HAS  (keg:  name,  ss#) 
HAS_A  (name,  ss#,  keg:  policy   number! 

(P0LICV_REC0R0)  UPDATES  (policy_number,  keg:  cal_date,  cal_topic) 
(P0LICV_REC0RD)  HAS  (keg:  policy   numberi 
(APS.F0RM  UPDRTES  (keg:  policg_number,  cal_date,  cal_tapic) 
COSTS  (policy_number,  keg:  tgpe) 
(PERSON)  HRS  (APPOINTMENT )  (keg:  name,  ss#) 
(APPOINTMENTS)  UPDATES  (keg:  name,  st#,  cal_date,  cal_topic) 
ENJOVS  (keg:  name,  ss#) 
OWES  (name,  ss#,  keg:  tgpe) 
EAANS  (keg:  name  ss#l 
BECOMES  (keg:  name,  ss#,  category,  date) 
OUJNS  (name,  ss#,  keg:  tgpe) 

FIGURE  3.10 
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HflUE (keg:  type) 

UJORKS_FOR  (key:  name,  ss#) 

TIME_TO_SEE  (day,  place,  key:  name,  ss#,  time) 

OTHERS-INSURED  (amt_of  ins,  relationship,  key:  policy_#,  name) 

(POLICY-RECORD)  HRS_R  (  name,  key:  policy_#) 

IS_R_600D  (name  ss#,  key:  time) 

SPENDS  (name  ss#,  key:  date) 


FIGURE  3.10    (COOT.) 


44 


RELATIONAL  DATABASE  MODEL 
DESI6N  4 

CLIENT  (s_ins_amt_couerage,s_birthdoy,  ct_address,  ct_phone_no, 
ct_occupation,  ct_wk_address,  ct_u>k_phone,  ct_birthday, 
r6f_made_by,  ref_phone_no,  misc,  income,  other_info, 
agent_name,  out_of_touin_sale,  sale_date,  ct_appt_time, 
cont_date,  cont_results,  keg:  client   name  spouse   namei 

PR0CT01DN  (ct_name,  issue_date,  amount,  prem_mode,  prem_due, 
issue_age,  yearly_prem,  riders,  pr_apl,  pr_diuid,  loan_amt, 
loan_int,  cash_ual_last,  cash_ual_cur,  cash_at_age_65,  pri-bene, 
ben_cont,  doc_form_rec,  doc_coll_date,  aps_not_rec, 
aps_rec_date,  keg:  compang_pro,  policg_no) 

CHILDREN  (ct_name,  chins_amt_couerage,  ch_birthy,  keg:  child_name) 

PRODAGSL  (agent_comm,  gen_ag_comm,  pro_stat,  compony_pro,  keg: 
agency   pro   name  I 

SOLDTOCT  (keg:  compang_pro,  pollcg_no,  ogency_pro_name) 

INCRCCT(debit_#,  lnc_amt,  agency_pro_name,  keg:  inc_date, 
res_for_inc) 

DAILVRDR  (action,  keg:  completion,  date,  cLnamei 

RDRNEED  (keg:  date,  ct_name,  client   name  I 

RGENCV  (generaLagent,  keg:  agencg_name) 

EHPRCCT  (eup-date,  agn_nome,  exp-desc,  eHp_cat_name,  enp_cat, 
exp_amt,  keg:  pu   number  i 


FIGURE  3.11 
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RELATIONAL  DHTRBflSE  MODEL 
0ESI6N  5 

AGENT  (license,  key:  agent_name) 

CLIENT  (occupation,  ivork_phone,  spouse,  home_phone,  salary, 
home_addr,  birthday,  work_addr,  keg:  name) 

POLICV  (policy_cash_ualue,  policy_contigent_benficiary, 

policy_diuidend,  policy_loan_amt,  policy_loan_int,  policy_rider, 
replacement_pollcy_riag,  prlmary_beneficlai,  plan,  mode, 
date_issued,  company,  amount,  keg:  pollcg_number) 

PRODUCTS  (company-name,  keg:  type) 

REMINDER-SYSTEM  (appointment,  call_date,  annual_reuiew,  keg:  date, 
agent_name) 

RGENCV_FINRNCIRL_DRTR  (agent_commission,indiuidual_income-amount, 
company_eHpense_amount,  company_income_amount, 
eHpense_description,  indiuiduai_eHpense_amount,  keg:  date, 
agent_name) 

CHILD  (child_name,  keg:  client-name) 


FIGURE  3.12 
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RELATIONAL  DRTRBRSE  MODEL 
DESIGN  6 

POLICV  (p_apl,  p_ctgnt_bnfcry,  p_prime_bnfcry,  p_cash_ualue, 

p_diu_opt,  p_face_amount,  p_insrd_inits,  p_loan_rate,  p_riders, 
co-company,  co-product,  c_ctient,  cl_prem_amt_due, 
cl_prem_amt_rcud,  cl_prem_date_due,  cl_prem_date_rcud, 
cl_prem_mode,  keg:  p_policg_no) 

COMPRNV_PRODUCT  (co_ouride_pct,  co-percent,  keg:  co_compang, 
co-product) 

CLIENT  (cLactiuity,  cl_ad dress,  cl_birthday,  cl_firm_address, 

cl_home_phone,  cLincame,  cl_insurance,  cl_occupatian,  cLother, 
cl_referred_by,  cl_referred_phone,  cl_spause_bday, 
cl_time_to_see,  cl_work_phane,  e_name,  keg:  cl_spouse, 
cl_cljent) 

EXPENSE  (eH_amount,  e_name,  keg:  en_dote,  eH_reoson) 

CHILD  (cl_child_bday,  cl_chlld_lnsur,  cLclient,  cLspouse,  keg:  cl_child) 

LICENSE  (keg:  co  product,  e_name  ) 

CALL  (cl-results,  cLclient,  cl_spou$e,  keg:  cl_call_dote,  cl_needi 

employee  (keg:  e_name) 

PRODUCT  (keg:  co_product  I 

COMPRNV  (keg:  co_compang) 


FIGURE  3.13 
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RELATIONAL  DATABASE  MODEL 
0ESI6N  7 

GENERAL-AGENT  (address,  ss#,  license_code,  pag_rate,  commission, 

key:  name) 
OFFICE-MANAGER  (address,  ss#,  phone_#  pay_rate,  key:  name) 
OFFICE-STAFF  (address,  ss#,  phone_#,  pay_rate,  key:  name) 
REPORT-FILE  (key:  a_s_name,  reports_type) 
REPORTS  (date,  key:  type) 
SOBAGENTS  (address,  ss#,  llcense_code,  pay_rate,  commission, 

key:  name) 
USER  (key:  subayents_nnme,  reports   tijpei 
LICENSED-RGENT  (key:  subagents  name,  product   tijpei 
PRODUCT  (price,  key:  type) 

COHPANV-AEPRESENTATIUE  (key:  praduct_type,  company_name  ) 
COMPANV  (address,  phone_#,  key:  name) 
SELLING-RGENT  (key:  subayents_name,  client_name) 
CLIENT  (ss#,  phone_#,  birthdate,  policy_types,  policy-*,  key:  name, 

address) 
SPOUSE  (ss#,  birthdate,  policy_types,  policy-*,  key:  name) 
CHILD  (ss#,  birthdate,  policy-types,  policy-*,  key:  name) 


FIGURE  3.14 
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Chapter  4:    Implementation 

In  this  chapter,  the  implementation  of  the  two  application  programs 
will  be  discussed.  The  original  application  problems  will  be  stated  as 
well  as  the  criteria  used  in  writing  the  application  programs.  Changes 
to  the  existing  database  designs  in  order  to  implement  the  programs 
will  be  mentioned. 

The  purpose  of  this  paper  is  to  determine  whether  differences  in 
database  designs  haue  an  affect  on  the  enuironment  theg  are  used  in. 
To  determine  this,  two  application  problems  were  chosen  to  represent 
on-line  (interactiue)  characteristics  of  a  database  and  batch  related 
processing.  Many  other  application  problems  could  have  been  used, 
howeuer,  these  were  chosen  as  representative  samples. 

The  first  problem  used  to  Illustrate  on  Interactiue  query  was  to 
produce  a  report  that  would  giue  all  the  products  (which  includes 
insurance,  IRR's,  and  annuities)  that  a  client  owns  and  the  name  of  the 
agent  that  sold  the  products  to  the  client.  The  second  problem  has 
characteristics  of  a  summary  report,  thus,  illustrating  batch  processing. 
In  the  second  application,  a  report  will  be  produced  that  glues  the 
dollar  ualue  of  all  products  sold  by  an  agent  during  a  specified  time 
period.  Subtotals  of  each  line  of  business  (insurance,  IRR's,  and 
annuities)  is  also  prouided. 
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One  of  the  methods  used  In  this  paper  to  determine  if  a  database 
design  had  an  effect  on  the  environment  it  was  used  in  was  to 
implement  the  same  application  problem  In  all  seven  designs  and  see  if 
there  were  noticeable  differences  in  the  number  of  lines  of  code  used  in 
writing  the  programs.  Since  the  goal  here  Is  to  minimize  the  number  of 
lines  of  code  it  was  necessary  to  haue  some  criteria  as  a  guideline  in 
writing  the  programs.  The  criteria  used  and  assumptions  to  reduce 
coding  are  listed  below: 

1)  Formatting  of  the  reports  was  regarded  as  non-essential  since 
more  lines  of  code  would  be  necessary  to  produce  this. 

2)  There  is  no  editing  on  data  that  is  asked  for  as  input.  It  is 
assumed  that  the  user  will  enter  everything  correctly.  This,  of  course, 
is  not  a  situation  one  would  want  to  haue  in  a  business  environment  for 
obvious  reasons. 

3)  fl  minimum  number  of  configuration  commands  were  used 
(e.g.,  SET  TALK  OFF). 

Essentially  only  those  lines  of  code  that  were  absolutely  necessary 
to  produce  the  required  information  without  regard  to  formatting  or 
editing  were  used. 

Another  goal  In  implementing  the  application  problems  was  to  try  to 
maintain  the  continuity  of  the  seven  database  designs.  Some  changes 
in  the  design  were  necessary  in  order  to  implement  the  two  application 
programs,     in  most  cases,   the  modifications  were   minor.      New 
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attributes  may  haue  had  to  haue  been  added  to  some  database  files. 
Some  of  the  attributes  in  a  file  structure  may  haue  been  changed 
(e.g.,  field  length  from  9  to  1 0). 

Rs  noted  in  chapter  three,  some  of  the  schemes  are  better  suited  to 
handle  certain  situations  than  others,  In  particular,  the  different 
product  lines.  In  order  to  work  with  the  different  kinds  of  products, 
seueral  of  the  schemas  had  to  be  modified.  To  minimize  the  degree  of 
restructuring  the  designs,  new  attributes  were  added  to  the  existing 
files  to  handle  the  uarious  products.  One  would  probably  not  want  to  do 
this  in  a  practical  situation  because  life  insurance,  IRfl's  and  annuities 
are  considerably  different  in  the  types  of  data  needed  to  maintain 
them.  For  the  purposes  here,  though,  it  serued  to  maintain  continuity 
of  a  design  before  and  after  the  Implementation  took  place. 

The  individual  modifications  to  each  design  will  now  be  discussed.  In 
design  one  an  attribute  ins:  type  was  changed  to  predct:nam'm  order  to 
make  it  consistent  with  the  attributes  used  in  the  entities  annuity  and 
ira  (see  Figure  4.1).  This  made  it  easer  to  use  the  APPEND  command  in 
implementing  the  first  program.  Prod; type  was  added  to  the  entity 
* ales  to  produce  the  second  report.  There  is  a  limitation  on  tracing  a 
sale  back  to  a  particular  client  because  there  is  not  a  client  name  field 
in  sales. 

Design  two  was  not  set  up  to  effectively  work  with  IRfl's  and 
annuities  so  the  plan  attribute  in  policyrc  was  used  to  include  those 
types  of  products,  fln  attribute,  type,  was  introduced  In  pollcyrc  to 
distinguish  the  different  product  lines.   The  ualues  used  were  INS  for 
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insurance  products,  ANN  for  annuity  products  and  IRfl  for  IRR's.  The 
attribute  face  amt,  numeric  width  type,  was  increased  from  8,2  to  9,2 
to  handle  policies  that  are  $100,000  and  aboue.  Rgentname  was  added 
to  poiiyrc  to  link  a  policy  with  the  agent  who  sold  it  (see  Figure  4.2) 

In  design  three,  it  was  necessary  to  add  several  attributes  to  the 
policy  entity.  These  included  type,  agent  and  plan  The  data  used  in 
these  attributes  are  similar  to  those  used  in  design  two.  Type 
distinguishes  the  different  product  lines  with  the  ualues  being  LIFE,  IRR 
and  ANN  (see  Figure  4.3). 

Design  four  had  only  one  change.  The  attribute  prodtype  was  added 
to  the  entity  proctoum  to  distinguish  the  product  lines  on  a  particular 
policy  (see  Figure  4.4). 

Design  flue  needed  only  one  change  also.  Rgaln,  the  reason  for  the 
modification  was  to  be  able  to  work  with  different  products  so  the  field 
poltype  was  added  to  the  entity  policy  (see  Figure  4.5). 

Design  sin  needed  an  attribute  in  order  to  produce  the  second  report 
so  date:sold  was  added  to  policy.  This  field  is  used  to  store  the  date  a 
particular  product  is  sold.  One  might  note  that  the  entity  client  also 
has  an  attribute  called  client  which  could  become  confusing  when 
writing  programs  using  this  file  (see  Figure  4.6) 

Design  seuen  needed  seueral  minor  changes  for  implementation. 
Paame  was  added  to  ciient^p  to  store  the  different  types  of  product 
plans  (e.g.  Whole  Life).  Ptype's  structure  was  changed  from  numeric  2 
to  character  2  in  order  to  produce  more  meaningful  results  for  the 
second  application  problem.   Ptype's  ualues  are  IR  for  IRR,   LF    for  life 
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products  and  RN  for  annuity  products.  Pamt's  width  was  changed  from 
a  numeric  8,2  to  9,2  to  handle  the  larger  dollar  ualue  policies  (see  Figure 
4.7) 

The  data  used  was  the  same  In  all  seuen  designs,  howeuer, 
depending  on  the  design,  some  attributes  may  be  used  in  one  case  and 
disregarded  in  another.  For  example,  one  design  may  link  a  policy  to  an 
agent  by  policy  number  while  another  design  may  use  a  client  ID 
number.  Each  database  was  established  with  fifteen  records  in  them 
representing  separate  policies.  By  hauiny  the  same  number  of  records 
in  the  files,  the  enecution  times  will  be  more  standardized.  To  look  at 
the  data  used  in  the  indiuidual  databases,  see  Figures  4.8-4.14.  Only 
the  attributes  that  were  used  in  the  programs  are  shown. 

To  execute  the  programs  simply  type  DO  program  name  (e.g.  Do 
DESIGN) R).  The  first  application  will  prompt  one  to  enter  a  client's 
name.  The  second  application  requires  one  to  enter  an  agent's  name 
and  the  starting  and  ending  date  which  are  used  as  a  time  frame  to  do  a 
search  on  to  retrieue  all  the  products  sold  by  an  agent  during  the 
specified  time  period. 

In  the  newt  chapter,  the  application  programs  will  be  compared 
showing  both  the  differences  in  the  number  of  lines  of  code  necessary 
for  implementation  and  the  execution  times  of  each. 
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DESIGN  1 


STRUCTURE  FOR  FILEl   AlCLIENT 
NUMBER  OF  RECORDS!    OOOIO 
DATE  OF  LOST  UPDATE  I  0*/09/87 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE 

WIDTH 

001 

CLIENT 

lID 

N 

005 

OOE 

CLIENT 

INAM 

C 

030 

003 

CLIENT: 

:BDD 

C 

030 

004 

CLIENT: 

iPH 

N 

010 

OOS 

CLIENT: 

lOCC 

C 

030 

006 

CL i EMP 

:ADD 

C 

030 

007 

CLlBUS: 

:PH 

N 

010 

OOS 

CLlREF: 

INAM 

c 

030 

009 

CLIENT: 

INC 

N 

009 

**  TOTAL  #* 

001 85 

STRUCTURE  FOR  FILEl   Al INSPOLCY. DBF 
NUMBER  OF  RECORDS!    00010 
DATE  OF  LAST  UPDATE  1  03/28/87 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE 

WIDTH 

DEC 

OOl 

CLIENT  1  ID 

N 

005 

OOE 

EMP I  ID 

N 

003 

003 

CO: NAME 

C 

030 

004 

INiPLCYlNO 

N 

010 

005 

INS  1  AMOUNT 

N 

009 

002 

006 

PRODCTlNAM 

C 

030 

007 

POLCY : DATE 

N 

006 

008 

POLCYlPRE 

N 

008 

002 

009 

WPl RIDER 

C 

001 

010 

ADBlRIDER 

C 

001 

01  1 

GIAlRIDER 

C 

001 

012 

CPBl RIDER 

c 

001 

013 

DIV, OPTION 

c 

001 

014 

POLlLNlPMT 

N 

009 

002 

015 

POL:LN:RT 

N 

004 

OOE 

016 

GUAR:  VALUE 

N 

009 

002 

017 

TOT! VALUE 

N 

009 

002 

018 

PRIMiBENIF 

C 

030 

019 

CNTGiBENIF 

C 

030 

#*  TOTAL  ## 

( 

DO  198 

FIGURE  4. 1 
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DESIGN  1 


STRUCTURE  FOR  FILEl   SiBNNUITY  .DBF 
NUMBER  OF  RECORDS:    OOOIO 
DBTE  OF  LAST  UPDATE :  09/13/86 
PRIMARY  USE  DATABASE 

DEC 


FLD 

NAME 

TYPE 

WIDTH 

001 

CLIENT:  ID 

N 

003 

002 

EMPlID 

N 

003 

003 

CO : NAME 

C 

030 

00* 

PRODCT:NAM 

c 

010 

005 

ANN: ACT: NO 

N 

005 

006 

ANN : DATE 

N 

006 

007 

ANN : AMT 

N 

009 

*#  TOTAL  *» 

00069 

STRUCTURE  FOR  FILE:  A: IRA 

NUMBER  OF  RECORDS:  00010 

DATE  OF  LAST  UPDATE:  03/06/B6 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE 

:  WIDTH 

OOl 

CLIENT: ID 

N 

005 

00£ 

EMP:ID 

N 

003 

003 

CO: NAME 

C 

030 

004 

PRODCT:NAM 

C 

030 

005 

I RA : ACT : NO 

N 

010 

006 

IRA: DATE 

N 

006 

007 

IRA I AMT 

N 

009 

#*  TOTAL  »* 

00094 

STRUCTURE  FOR  FILE:   A: EMPLOYEE. DBF 

NUMBER  OF  RECORDS:    00003 

DATE  OF  LAST  UPDATE:  04/05/87 

PRIMARY  USE  DATABASE 

FLD        NAME       TYPE  WIDTH    DEC 


001       EMP 

I  ID 

N 

003 

002      EMP : 

INAME 

C 

030 

003      EMP; 

lADDRES 

C 

030 

004      JOB 

ITITLE 

c 

020 

##  TOTAL  ## 

00084 

STRUCTURE  FOR  FILE:  A:SALES 

NUMBER  OF  RECORDS:  00015 

DATE  OF  LAST  UPDATE:  04/09/87 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE 

WIDTH 

DEC 

001 

EMP: ID 

N 

003 

OOE 

CO: NAME 

C 

030 

003 

PROD: TYPE 

c 

015 

004 

PROD: NAME 

c 

030 

005 

SALES: AMT 

N 

009 

002 

006 

SALE: DATE 

N 

006 

007 

COMM:SOLD 

N 

007 

002 

008 

NO : OF : SAL 

N 

003 

»•  TOTAL  »♦ 

00104 

FI 

SURE  4 . 1 

(CONT. ) 
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DESIGN  2 


STRUCTURE  FOR  FILEl 

Al 

POLICY RC. 

DBF 

NUMBER 

DF  RECORDS! 

00030 

DATE  OF 

LAST  UPDATE  1 

04/09/87 

PRIMARY 

USE  DATABASE 

FLD 

NAME 

TYPE  HID 

DEC 

001 

CDNAME 

C 

OSS 

002 

COADDRESS 

C 

042 

003 

CLIENTNAME 

c 

026 

004 

AGENTNBME 

c 

026 

005 

TYPE 

c 

003 

006 

PLAN 

c 

030 

007 

PREMIUM 

N 

008 

002 

OOB 

APL 

N 

001 

009 

RIDERS 

C 

003 

010 

AGEINSURD 

N 

003 

on 

DATE ISSUE 

N 

OOB 

012 

FACEAMT 

N 

009 

002 

013 

INSURINIT 

C 

003 

014 

INSURNAME 

c 

026 

015 

POLICYNUMB 

N 

012 

016 

PREMIUMDUE 

N 

OOB 

017 

MODE 

C 

009 

01S 

CONTBENIF 

C 

026 

019 

PRIMBENIF 

c 

026 

020 

CASHVALUE 

N 

008 

002 

021 

LINTRATE 

N 

002 

022 

LOANAMT 

N 

OOB 

002 

023 

LOAN 

N 

001 

024 

DIVOPT 

N 

001 

025 

QROSYRPREM 

N 

008 

002 

»»  TOTAL  »» 

00324 

FIGURE    4.2 
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DESIGN  3 


STRUCTURE  FDR  FILE.  AiPOLICY   .DBF 

NUMBER  OF  RECORDS  I  00030 

DATE  OF  LAST  UPDATE  I  04/09/87 

PRIMARY  USE  DATABASE 

FLD        NAME  TYPE  WIDTH    DEC 

001  POLICYlNO  C     009 

002  AGENT  C     023 

003  CO: NAME  C     020 

004  EXP: DATE  C     006 

005  REP:  DATE  C     006 

006  AMTiOFtlNS  N     007  ■ 
■007      APL  C     001 

008  NAME  C     020 

009  SS  C     009 

010  DATE: SOLD  C  006 
Oil       TYPE  C     004 

012  PLAN  C     025 

013  DIV:OPT  C     001 

014  LOANiAMT  N     007 

015  LOAN:RATE  N     010 

016  PRI:BEN  C  020 
017'  CONTIN:BEN  C  020 
*»  TOTAL  *#  00197 


FIGURE  4.3 
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DESIGN  4 


STRUCTURE  FOR  FILEl  B.PROCTOWN. DBF 

NUMBER  OF  RECORDSl  00015 

DBTE  OF  LAST  UPDBTE:  04/09/87 
PRIMBRY  USE  DBTBBBSE 


FLD 
001 
002 
003 
004 
005 
006 
007 

ooa 

009 
010 
Oil 
012 
013 
014 
015 
016 
017 

018 

019 

020 

021 

022 

023 

024 

025 

026 

027 


»*  TOTAL  ♦* 


NBME 
PRODTYPE 
COMPPROV 
POLICYNO 
CTNflME 
ISSUDBTE 
AMOUNT 
PREMMODE 
PREMDUE 
ISSUBGE 
YEBRPREM 
RIDERS 
PRAPL 
PREMDIV 
LOBNBMT 
LOHNINT 
CBSHVLAS 
CBSHVCUR 
CVLYRBAR 
CVCYRGBR 
CBSHVG65 
CBSHV65 
PRIMBENE 
SECBENE 
DOCFORMR 
DOCCALLD 
BPSNORRE 
APSRDBTE 


TYPE  WIDTH    DEC 


004 

020 
007 
020 
006 
007 
004 
007 
002 
007 
004 
003 
004 
008 
003 
007 
007 
007 
007 
007 
007 
020 
020 
OOl 
006 
001 
006 
00203 


002 


002 
002 


STRUCTURE  FOR  FILE I   BiAGTCTS   .DBF 

NUMBER  OF  RECORDSl    00010 

DATE  OF  LAST  UPDATE!  04/09/87 

PRIMARY  USE  DATABASE 

FLD        NAME       TYPE  WIDTH 

001  BGNNAME        C     020 

002  CTNAME         c     020 
*»  TOTAL  *«  00041 


DEC 


FIGURE  4.4 
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DESIGN  5 


STRUCTU 

RE  FOR  FILEl 

Ai 

CLIENT 

NUMBER 

OF  RECORDS  1 

000  IS 

DATE  OF 

LAST  UPDBTEl 

04/20/87 

PRIMARY 

USE  DATABASE 

FLO 

NAME 

TYPE  WIDTH 

001 

CLTNAME 

C 

025 

002 

CLTHOME 

N 

007 

003 

CLTINSUR 

N 

00  7 

00* 

CLTOREAL 

N 

007 

005 

CLTPERSL 

N 

007 

006 

CLTSALRY 

N 

006 

007 

CLTTCASH 

N 

007 

008 

CLTCNAME 

C 

025 

009 

CLTFBDDR 

C 

040 

010 

CLTHADDR 

C 

040 

on 

CLTOCCUP 

c 

020 

012 

CLTWNAME 

c 

025 

013 

CLTWKPHO 

N 

010 

014 

CLTPOLNO 

N 

010 

01S 

CLTPPDLQ 

N 

001 

»»  TOTAL  •» 

00238 

STRUCTURE  FOR  FILEl  A. AGENT 

NUMBER  OF  RECORDS:  00010 

DATE  OF  LAST  UPDATE:  04/05/87 
PRIMARY  USE  DATABASE 


FLD         NAME 

TYPE  WIDTH 

001       ASTNAME 

C 

025 

002      AETTYPE 

c 

001 

003      AETLIC 

c 

010 

004      ABTCOMM 

N 

008 

005      AGTCNAME 

C 

025 

**  TOTAL  »# 

00070 

STRUCTURE  FOR  FILE:  B:POLICY 

NUMBER  OF  RECORDS:  00015 

DATE  OF  LAST  UPDATE:  04/05/87 
PRIMARY  USE  DATABASE 


FLD 

NAME 

TYPE  WIDTH 

001 

POLNO 

N 

010 

002 

POLAMONT 

N 

008 

003 

POLAMT 

N 

004 

004 

POLCMPNY 

C 

015 

005 

POLDATE 

N 

006 

006 

POLMODE 

C 

0O2 

007 

POLTYPE 

c 

004 

008 

POLPLAN 

c 

030 

009 

POLVALUE 

N 

007 

010 

POLCBEN 

C 

025 

Oil 

POLPBEN 

c 

025 

012 

POLRFLAE 

N 

001 

•»  TOTAL  *» 

00138 

FIGURE  4.5 
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DESIGN  6 


STRUCTURE  FOR  FILEi  AlCLIENT 

NUMBER  OF  RECORDS  I  OOOIO 

DATE  OF  LAST  UPDATE!  04/09/87 
PRIMARY  USE  DATABASE 


FLD 
001 
002 
003 
004 
005 
006 
007 
008 
009 
010 
Oil 
012 
013 
010 
015 
016 


NOME 
CLIENT 
SPOUSE 
ACTIVITY 
ADDRESS 
BIRTHDAY 
FlADDRESS 
H: PHONE 
INCOME 
INSURANCE 
OCCUPATION 
OTHER 
REFEREDlBY 
Si  BIRTHDAY 
TIME:TOlSE 
U : PHONE 
ENAME 


TYPE  WIDTH 


**  TOTAL  #* 


020 
025 
025 
025 
008 
025 
010 
010 
020 
025 
025 
025 
008 
020 
010 
020 
00302 


STRUCTURE  FOR  FILEl 
NUMBER  OF  RECORDS r 
DATE  OF  LAST  UPDATE! 
PRIMARY  USE  DATABASE 


FLD 
001 
002 
003 
004 
005 
006 
007 
008 
009 
010 
Oil 
012 
013 
014 
015 
016 
017 
018 
019 


NAME 
POLICYNO 
CLIENT 
COMPANY 
PRODTYPE 
PRODUCT 
APL 

PiBENEFIC 
CASHiVAL 
DIVrOPT 
DATE! SOLD 
FACE  I AMT 
INSRDlINIT 
LOAN ! RATE 
RIDERS 
PREMiAMTDU 
PREMlAMTRC 
PREMDATEDU 
PREMDATERC 
PREMMODE 


AlPOLICY 

00015 

04/09/87 

TYPE  WIDTH 

C  020 

C  020 

C  020 

C  004 

C  020 

C  001 

C  025 

N  010 

C  001 

N  006 

N  010 

C  003 

N  005 

C  020 

N  01O 

N  010 

C  008 

C  008 

C  002 
0O2O4 


002 
002 


FIGURE  4.6 
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DESIGN  7 


STRUCTURE  FOR  FILEl  A|CLIENT_P. DBF 

NUMBER  OF  RECORDS!  00015 

DATE  OF  LAST  UPDATE!  04/03/87 
PRIMARY  USE  DATABASE 


FLD 

NOME 

TYPE  WIDTH 

DEC 

001 

CLNAME 

C 

018 

ooa 

CONAME 

C 

030 

003 

DATEISS 

C 

006 

004 

PTYPE 

c 

ooa 

005 

PNAME 

c 

023 

006 

PAMT 

N 

009 

002 

007 

PNUM 

c 

OEO 

008 

BENNAME 

c 

04e 

009 

PREMMODE 

C 

oos 

010 

PREMAMT 

N 

008 

0O2 

Oil 

PREMDUE 

N 

008 

OOE 

012 

SELNAME 

C 

OEO 

»*  TOTAL  *» 

00189 

FIGURE  4.7 
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DESIGN  1  DOTH 


CLIENT:  ID    CLIENT:  NAM 
10001  Ballard,  Job 
40001  Gould,  Pat 
30OO3  Evans,  Bob 
30013  Sanford,  William 
50251  Simpson,  Charlotte 
90005  Bond,  Steve 
42055  Wells,  Charles 
30889  Seeker,  Jan 

9841  Tiffany,  Susan 
57896  0* ford,  Dan 


CLIENT:ID  EMP:ID  PR0DCT:NAM 

40OO1  111  Whole  Life 

57896  202  10  Pay  Term 

40404  284  Universal  Life 

52201  111  10  Pay  Whole  Life 

30889  284  Single  Premium  Life 

66844  202  Universal  Life 

99965  111  Discoverer  Life 

42055  111  10  Year  Paid  Life 

50251  284  Term 

22992  284  Paid  Up  Life 


CLIENT: ID  EMP:ID  PR0DCT:NAM 

40001  111  FPB 

44875  202  SPB 

48876  284  FPB 

9841  202  FPB 

54912  202  SPB 

30013  111  FPB 

48600  111  SPB 

90005  202  FPB 

42055  202  SPB 

34001  202  FPB 

CLIENT:ID  EMP:ID  PRODCT:NflM 

57575  111  Fidelity  Magellan 

90005  202  Money  Market 

57896  284  Putnam  High  Yield 

22225  284  Mutual  Funds 

33386  284  High  Yield  Trust 

10001  111  Fidelity  Overseas 

30003  202  Ginnie  Mae 

57896  202  Vista 

49612  202  Bonds 

50891  284  Trust  Fund 


■EMP:ID  EMP:NAME 
111  Reed,  Richard 
284  Thompson,  Sharon 
202  Doe,  Ronald 


FIGURE  4.8 
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DESIGN  1  DRTR 


202  Insurance 

111  Annuity  ' 

202  IRA 

£02  Annuity 

284  Insurance 

HI  Annuity 

111  I RA 

284  IRA 

284  Insurance 

202  Annuity 

202  IRA 

111  Insurance 

202  Annuity 

202  IRA 


PROD: NAME 

Whole  Life 

10  Pay  Term 

FPA 

Vista 

SPA 

Term 

FPA 

Fidelity  Dverse 

Putnam  High  Yie 

Single  Premium 

FPA 

Ginnie  Mae 

10  Year  Paid  Li 

FPA 

Money  Market 


50000.00   860105 

1000.00 

2000. 00 

4000.  00 
100000.00 

2000.  00 
10000.00 

5000. 00 
25000.  00 
10000.00 

1000.00 
50000.  00 

5000. 00 

2000. 00 


860325 
861225 
861005 
860125 
860125 
860110 
860918 
860707 
860515 
860715 
860131 
860115 
860201 


FIGURE  4.8  (CONT. 
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DESIGN  2  DHTfl 


.CLIEOTNAME   DATEISSUE 

FAGEAMT 

AGENTNAME 

Ballard,  Joe 

Reed,  Richard 

860110 

10000. 

00 

Gould,  Pat 

Reed,  Richard 

860111 

20000. 

00 

Gould,  Pat 

Reed,  Richard 

B603E5 

1000. 

00 

Evans,  Bob 

Doe,  Ronald 

8607 15 

1000. 

00 

Sanford,  William 

Reed,  Richard 

860135 

2000. 

00 

Simpson,  Charlotte 

Thompson,  Sharon 

860125 

100000. 

00 

Bond,  Steve 

Doe,  Ronald 

860301 

2000. 

,00 

Bond,  Steve 

Doe,  Ronald 

8601 15 

5000. 

,00 

Uells,  Charles 

Reed,  Richard 

860131 

50000, 

00 

Uells,  Charles 

Reed,  Richard 

861005 

4000, 

,00 

Seeker,  Jan 

Thompson,  Sharon 

860707 

25000, 

,00 

Tiffany,  Susan 

Doe,  Ronald 

860515 

10000, 

,00 

Oxford,  Dan 

Doe,  Ronald 

860105 

50000. 

.00 

Oxford,  Dan 

Thompson,  Sharon 

860918 

5000, 

.00 

Oxford,  Dan 

Doe,  Ronald 

861225 

2000 

.00 

TYPE   PLAN 
IRP  Fidelity  Overseas 

INS  Whole  Life 

RNN  FPP 

IRP.  Ginnie  Mae 

ANN  FPP. 

INS  Term 

IRP.  Money  Market 

P.NN  FPP 

INS  10  Year  Paid  Life 

ANN  SPfl 

INS  Single  Premium  Life 

ANN  FPP 

INS  10  Pay  Term 

IRP.  Putnam  High  Yield 

IRP   Vista 


FIGURE    4.9 
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DESIGN  3  DATA 


-     AGENT 

Reed,  Richard 

rseas 

Reed,  Richard 

Dot,  Ronald 

Doe,  Ronald 

Doe,  Rona 1 d 

Doe,  Ronald 

Doe,  Ronald 

Thompson,  Sharon 

Reed,  Richard 

Reed,  Richard 

Thompson,  Sharon 
Yield  Trust 
Reed,  Richard 

Doe,  Ronald 

Thompson,  Sharon 
urn  Life 
Reed,  Richard 
Life 


AMT:OF:INS     NftME 
10000   Ballard,     Joe 

20000  Gould,  Pat 

£000  Oxford,  Dan 

5000  Bond,  Steve 
10000  Tiffany,  Susan 

1000  Evans,  Bob 
50000  Oxford,  Dan 
100000  Simpson,  Charlotte 

4000  Wells,  Charles 

1000  Gould,  Pat 

5000  Oxford,  Dan 

£000  Sanford,  William 

£000  Bond,  Steve 
£5000  Seeker,  Jan 
50000  Well*,  Charles 


DATE  :S0LD 
011086 

TYPE 
IRA 

PLAN 
Fidelity  Dve 

011186 

LIFE 

Whole  Life 

122586 

IRA 

Vista 

011586 

ANN 

FPA 

0S1S86 

PNN 

FPA 

071586 

IRA 

Ginnie  Mae 

010586 

LIFE 

10  Pay  Term 

oiasas 

LIFE 

Term 

100586 

ANN 

SPA 

032586 

ANN 

FPA 

091886 

IRA 

Putnam  High 

012586 

ANN 

FPA 

020186 

IRA 

Money  Market 

070786 

LIFE 

Single  Premi 

013186 

LIFE 

10  Year  Paid 

FIGURE  4.10 
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DESIGN  4  DRTH 


AGNNAME 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 


CTNAME 
Ballard,  Joe 
Simpson,  Charlotte 
T  i  f f any,  Susan 
Oxford,  Dan 
Mel  Is,  Charles 
Gould,  Pat 
Seeker,  Jan 
Evans,  Bob 
Bond,  Steve 
Sanford,  William 


rPRODTYPE  COMPPROV 

IRA   Fidelity  Overseas 

IRA   Vista 

LIFE  10  Year  Paid  Life 

IRA   Ginnie  Mae 

IRA   Money  Market 

LIFE  Single  Premium  Life 

LIFE  Whole  Life 

LIFE  10  Pay  Term 

ftNN   FPA 

ANN   FPA 

ANN   SPA 

ANN   FPA 

LIFE  Term 

IRA   Putnam  High  Yield 

ANN   FPA 


CTNAME 
Bal lard,  Joe 
Oxford,  Dan 
Mel  Is,  Charles 
Evans,  Bob 
Bond,  Steve 
Seeker,  Jan 
Gould,  Pat 
Oxford,  Dan 
Tiffany,  Susan 
Sanford,  William 
Wells,  Charles 
Bond,  Steve 
Simpson,  Charlotte 
Oxford,  Dan 
Gould,  Pat 


SSUDATE 

ATOUNT 

860110 

10000 

86iaa5 

2000 

860131 

50000 

860715 

1000 

860201 

2000  PR0CT0WN 

860707 

25000 

860111 

£0000 

860105 

50000 

8605 1 5 

10000 

860125 

2000 

861005 

4000 

860115 

5000 

860125 

100000 

860918 

5000 

860325 

1000 

FIGURE  4.11 
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DESIGN  5  DRTfl 


•CLTNAME 
Bal lard,  Joe 
Oxford,  Dan 
Weils,  Charles 
Evans,  Bob 
Bond,  Steve 
Seeker,  Jan 
Gould,  Pat 
Oxford,  Dan 
Tiffany,  Susan 
Sanford,  William 
Wells,  Charles 
Bond,  Steve 
Simpson,  Charlotte 
Oxford,  Dan 
Gould,  Pat 


7559 
100785 
200784 
865434 
568693 
14761 
922264 
215900 
697823 
533974 
863460 
842669 
699380 
384917 
769155 


AGTNAME 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 


AGTCNAME 
Ballard,  Joe 
Simpson,  Charlotte 
Tiffany,  Susan 
Oxford,  Dan 
Wells,  Charles 
Gould,  Pat 
Seeker,  Jan 
Evans,  Bob 
Bond,  Steve 
Sanford,  William 


P0LN0  POLTOPE   P0LPIAN 

785940  IRfl   Fidelity  Overseas 

100785  IRA   Vista 
200784  LIFE  10  Year  Paid  Life 
S65434  IRA   Ginnie  Mae 
568693  IRfl   Money  Market 

14761  LIFE  Single  Premium  Life 
922264  LIFE  Whole  Life 
215900  LIFE  10  Pay  Term 
697823  ANN   FPfl 
533974  ANN   FPA 
863460  ANN   SPA 
842669  ANN   FPA 
699380  LIFE  Term 
384917  IRA   Putnam  High  Yield 
769155  ANN   FPA 


P0LDATE 

P0LAM0NT 

860110 

10000 

as lass 

2000 

B60131 

50000 

860715 

1000 

860201 

2000 

860707 

25000 

860111 

20000  POLICY 

860105 

50000 

860515 

10000 

860125 

2000 

861005 

4000 

860115 

5000 

860125 

100000 

860918 

5000 

860325 

1000 

FIGURE  4.12 
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DESIGN  6  DRTR 


•   CLIENT 
Bal lard,  Joe 
Simpson,  Charlotte 
Tiffany,  Susan 
Oxford,  Dan 
Nells,  Charles 
Gould,  Pat 
Seeker,  Jan 
Evans,  Bob 
Bond,  Steve 
Sanford,  William 


ENAME 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 
Reed,  Richard 
Thompson,  Sharon 
Doe,  Ronald 
Doe,  Ronald 
Reed,  Richard 


.  CLIENT 

PRODTYPE 

PRODUCT 

DATE ISOLD 

FACE:AMT 

Ballard,  Joe 

IRH 
IRA 

8601 10 
861225 

10000. 00 
2000.  00 

Oxford,  Dan 

Vista 

Wells,  Charles 

LIFE 

10  Year  Paid 

Life 

860131 

50000.  00 

Evans,  Bob 

IRH 

Ginnie  Mae 

86071S 

1000.00 

Bond,  Steve 

IRA 

Money  Market 

860201 

2000. 00 

Seeker,  Jan 

LIFE 

Single  Premium 

Life 

860707 

25000. 00 

Gould,  Pat 

LIFE 

Whole  Life 

860111 

20000.  00  POLICY 

Oxford,  Dan 

LIFE 

10  Pay  Term 

860103 

50000.  00 

Tiffany,  Susan 

ANN 

FPA 

860515 

10000.00 

Sanford,  Uilliam 

ANN 

FPA 

860125 

2000. 00 

Wells,  Charles 

ANN 

SPA 

861005 

4000.  00 

Bond,  Steve 

ANN 

FPA 

860115 

5000. 00 

Simpson,  Charlotte 

LIFE 

Term 

860125 

100000.00 

Oxford,  Dan 

IRA 

Putnam  High  V 

ield 

860918 

5000. 00 

Gould,  Pat 

ANN 

FPA 

860325 

1000.00 

FIGURE  4.13 
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DESIGN  7  DRTR 


.  CLNAME 
Ballard,  Joe 

Gould,  Pat 
Oxford,  Dan 
Bond,  Steve- 
Tiffany,  Susan 
Evans,  Bob 
Oxford,  Dan 
Simpson,  Char  lot  ti 
Walls,  Charles 
Gould,  Pat 
Oxford,  Dan 
Sanford,  Ml  11  lam 
Bond,  Steve 
Seeker,  Jan 
Hells,  Charles 


DATEISS  PTYPE    PNAME  PAMT 

860110  IR  Fidelity  Overseas  10000.00 

860111  LF  Whole  Life  £0000.00 
861225  IR  Vista  2000.00 
860115  AN  FPA  5000.00 
860515  AN  FPA  10000.00 
860715  IR  Ginnie  Mae  1000.00 
860105  LF  10  Pay  Term  50000.00 
860125  LF  Term  100000.00 
861005  ftN  SPA  4000.00 
860325  AN  FPA  1000.00 
860918  IR  Putnam  High  Yield  Trust  5000.00 
860125  AN  FPA  2000. OO 
860201  IR  Money  Market  2000.00 
860707  LF  Single  Premium  Life  25000.00 
860131  LF  10  Year  Paid  Life  50000.00 


SELNAME 
Reed,  Richard 

Reed,  Richard 

Doe,  Ronald 

Doe,  Ronald 

Doe,  Ronald 

Doe,  Ronald 

Doe,  Ronald 

Thompson,  Sharon 

Reed,  Richard 

Reed,  Richard 

Thompson,  Sharon 

Reed,  Richard 

Doe,  Ronald 

Thompson,  Sharon 

Reed,  Richard 


CLIENT  P 


FIGURE    4.14 
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CHAPTER  5:  Application  Program  Analysis 

In  this  chapter,  a  comparison  of  the  application  programs  is  made. 
The  two  criteria  used  in  the  analysis  is  the  total  lines  of  code  used  and 
the  execution  time  for  each. 

Since  these  programs  do  not  haue  any  editing  in  them  it  is 
important  to  know  that  the  user  is  assumed  to  enter  the  data  correctly. 
Should  the  user  input  inualid  data  (wrong  data,  or  clients  that  are  not 
on  the  file),  in  some  cases,  a  report  will  still  be  generated  giuing  the 
appearance  that  the  input  was  ualid.  DBase  II  makes  a  distinction 
between  upper  and  lower  case  letters  so  if  a  name  is  entered  in  lower 
case  while  it  is  stored  in  upper  and  lower  case,  it  will  be  as  if  the  name 
can  not  be  found  on  the  file. 

To  measure  the  execution  time,  each  application  was  run  three 
times  using  a  stopwatch,  with  hundredths  of  a  second  accuracy,  to  do 
the  timing.  In  the  first  application  program  the  timed  portion  was  from 
the  moment  the  enter  key  was  hit  after  the  input  was  entered  to  the 
time  the  report  was  finished.  In  the  second  application  program,  the 
timed  portion  was  from  the  moment  the  enter  key  was  struck  after  the 
input  was  entered  to  the  time  the  report  started  printing.  The  reason 
for  timing  to  the  beginning  of  the  report  being  printed  was  because  the 
report  tended  to  be  longer  so  in  order  to  print  it,  the  computer  may 
haue  had  to  make  several  disk  accesses  which  slowed  down  oueroll 
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execution  time  considerably.      After   the   three    timings   for   each 
application  was  completed  their  auerage  was  calculated. 

Figures  5.1.1  through  5.7.3  are  the  indiuidual  programs,  the  report 
form  layouts,  and  sample  output  from  each  application.  Figure  5.8  giues 
a  summary  of  the  number  of  lines  of  code  used  for  each  program  and 
the  execution  times  for  each  application. 

In  looking  at  the  first  application  program  which  returns  all  the 
policies  a  client  owns  and  the  agent  who  sold  the  policies,  designs  two, 
three,  and  seuen  haue  the  least  lines  of  code.  Only  one  file  needed  to 
be  accessed  in  each  case  to  obtain  the  necessary  data  to  produce  the 
report  required. 

Design  one  haulng  13  entitles  and  23  relationships  required  the  most 
lines  of  code  (21)  euen  though  the  schema  Is  probably  the  best  In 
handling  the  different  product  lines.  It  is  easily  seen  that  the  more 
files  that  are  accessed,  causes  an  increase  in  the  coding,  due  to  the 
creation  of  temporary  files  through  the  use  of  JOIN  and  COPV 
commands. 

Design  four  has  9  entities  and  8  relationships  and  is  similar  to 
design  two  which  has  9  entities  and  10  relationships  but  only  two  files 
needed  to  be  accessed  from  the  database  rather  then  the  flue  that 
were  accessed  in  design  one.  This  meant  fewer  lines  of  code  were 
necessary  to  implement  design  four. 

Design  flue  (7  entities  and  7  relationships  land  design  six  (9  entities 
and  9  relationships)  resemble  each  other  in  that  when  executed,  the 
agent's  name  who  sold  the  products  to  the  client  will  appear  first  and 
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then  the  products  the  client  owns.  Because  there  is  nothing  which  links 
an  agent  to  the  policg,  in  both  cases  it  has  to  be  assumed  that  all  the 
client's  products  are  sold  by  the  same  agent. 

In  the  second  application  program  which  giues  all  the  products 
sold  by  an  agent  in  the  specific  time  period,  design  flue  has  the  most 
lines  of  code  (23).  This  is  due  to  the  additional  trauersing  that  had  to  be 
done  in  order  to  link  the  policy  number  to  a  client. 

Design  siH's  code  was  almost  identical  to  design  flue's  but  one  less 
file  had  to  be  accessed  because  a  client's  name  could  directly  be  linked 
to  a  policy.  This  decreased  the  number  of  lines  of  code  necessary  to 
implement  the  second  application. 

Design  four  required  the  same  number  of  lines  of  code  as  design 
siH  (19).  The  schemas  are  closely  related  to  each  other  so  this  could  be 
eitpected. 

Designs  two,  three,  and  seuen  again  required  the  least  coding.  This 
is  due  to  the  fact  that  only  one  file  had  to  be  accessed  to  retrfeue  the 
necessary  information  to  produce  the  report. 

Reuiewing  the  enecution  times  for  each  application  reueals  that 
for  the  on-line  applications,  the  number  of  lines  of  code  and  the  types 
of  commands  used  plays  an  important  role  in  the  ouerall  run  time. 
Design  one  which  has  the  most  file  accesses  and  uses  the  most  COPV 
and  RPPEND  commands  has  run  times  which  double  and  nearly  triple 
most  of  the  others.  It  Is  surprising  to  note  that  the  batch  application 
for  design  one  runs  considerably  faster  than  all  the  designs  eHcept 
seuen. 
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During  the  analysis  of  the  second  application  program  written  for 
design  sin,  it  was  necessary  to  rewrite  it  since  the  same  thing  could  be 
accomplished  using  one  less  file  access.  This  helped  decrease  the 
execution  time  by  approximately  18%. 

It  appears  that  a  determining  factor  in  the  length  of  coding  as 
well  as  the  execution  times  is  how  many  files  haue  to  be  accessed  to 
retrieve  the  necessary  data.  The  number  of  entities  and  relationships  a 
design  has  is  not  as  Important  as  how  the  attributes  are  arranged  with 
the  entities  and  relationships  in  making  up  the  ouerall  design.  This  can 
be  shown  by  looking  at  designs  one  and  three.  They  haue  the  most 
entities  and  relationships  among  the  seven  designs,  howeuer,  design 
one  used  the  most  lines  of  code  in  the  first  application  while  design 
three  used  the  least. 
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DESIGN  1 


PROGRAM  1 
set  talk  off 

accept  "Enter  Client's  Name  (Last,  First)  "  to  clnt 
use  client 

locate  for  clientinam  =  clnt 
store  clientiid  to  clnt i id 
use  inspolcy 

copy  to  tempi  field  empi id, prodct :nam  for  clntiid  =  clientiid 
use  annuity 

copy  to  temp2  field  empt id, prodct mam  for  clnt t id  ■  clientiid 
use  ira 

copy  to  temp3  field  impi id, prodct mam  for  clntiid  -  clientiid 
use  tempi 
append  from  tempS 
append  from  t«mp3 
use  tempi 
select  secondary 
use  employee 
select  primary 

join  to  newfile  for  empiid  -  s. empiid  field  prodct i nam, empi name 
use  newfile 
list 


PROGRAM  2 
set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  "  to  start idatl 
input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  endidate 
accept  "Enter  agent's  name  (Last,  First)  "  to  agent  id 
use  employee 

locate  for  em  pi  name    =*  agent  id 
store  empiid  to  empfound 
use  sales 
copy  to  tempi  for  empiid  =  empfoundt 

.and.  saleidate  )  •»  start:date( 

-and.  saleidate  (=  endidate 
use  tempi 

sort  on  proditype  to  tempS 
use  tempS 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.1.1 
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DESIGN  1 
REPORT  FORM    SRLESRGT 


ENTER  OPTIONS,  M-LEFT  MARGIN,  L-LINES/PAGE,  W=PAGE  WIDTH 

PBGE  HEADING?  <Y/N>  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REQUIRED?  <Y/N)  y 

SUBTOTALS  IN  REPORT?  <Y/N>  y 

ENTER  SUBTOTALS  FIELD:  prod: type 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADING:  TOTAL  FOR  PRODUCT  TYPE: 

COL      WIDTH, CONTENTS 

001      30, prod: name 

ENTER  HEADING:  PRODUCT  NAME 

OOS       12,s.le!iamt 

ENTER  HEADING:  AMOUNT 

ARE  TOTALS  REQUIRED?  (Y/N)  y 

003 


FIGURE  5.1.2 


76 


DESIGN  1 
PDOGRRM  EHECUTIONS 


.  do  designla 

Enter  Client's  Name  (Last,  First)  :6ouldt  Pat 

00001  Whole  Life  Reed,  Richard 

00002  FPfl  Reed,  Richard 


.  do  designla 

Enter  Client's  Name  (Last,  First)  :0xford,  Dan 

00001  10  Pay  Term  Doe,  Ronald 

00002  Putnam  High  Yield  Thompson,  Sharon 

00003  Vista  Doe,  Ronald 


.  do  designla 

Enter  Client's  Name  (Last,  First)  I  Seeker,  Jan 

00001   Single  Premium  Life  Thompson, 


PRODUCT  NAME  AMOUNT 

«  TOTAL  FOR  PRODUCT  TYPE  I   Annuity 

FPP.  £000.  00 

*»  SUBTOTAL  »• 

2000. 00 


♦  TOTAL  FOR  PRODUCT  TYPE! 
Fidelity  Overseas 
•»  SUBTOTAL  •* 


*  TOTAL  FOR  PRODUCT  TYPE  I   Insurance 

Whole  Life  20000.00 

10  Year  Paid  Life  30000.00 
»»  SUBTOTAL  »• 


»»  TOTAL  »« 


FIGJRE  5.1.3 
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DESIGN  2 


PROGRAM  1 
set  talk  off 

accept  "Enter  CI  lent  *  s  Name  (Last,  First  >  "  to  clnt 
use  pol icyrc 

copy  to  tempi  field  cl ientname, agent name, plan  for  cl ient name3clnt 
use  tempi 
list 


PROGRAM  2 

set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  "  to  start :date 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  end:date 

accept  "Enter  agent's  name  (Last,  First)  "  to  agentid 

use  pol lcyrc 

copy  to  tempi  for  agentname  *  agent  id  j 

■  and.  date issue  > ■  start : date ; 

.and.  dateissue  <■  endtdate 
use  tempi 

sort  on  type  to  temp2 
use  tempS 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.2.1 
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DESIGN  2 
REPORT  FORM    SRLESflGT 


ENTER  OPTIONS,  M=LEFT  MARGIN,  L=LINES/PAGE,  U=PAGE  WIDTH 

PPGE  HEADING?  (Y/N>  y 

ENTER  PPGE  HERDING:  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REQUIRED?  (Y/N)  y 

SUBTOTALS  IN  REPORT?  (Y/N)  y 

ENTER  SUBTOTALS  FIELDl  type 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADING!  TOTAL  FOR  PRODUCT  TYPE! 

COL      U I DTH, CONTENTS 

001      30, plan 

ENTER  HEADING!  PLAN 

008       12, faceamt 

ENTER  HEADING!  AMOUNT 

ARE  TOTALS  REQUIRED?  (Y/N)  y 


FIGURE  5.2.2 
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DESIGN  2 
PR06RAM  EHECUTIONS 


.  do  designSa 

Enter  Client's  Name  (Last,  First)  tGould,  Pat 

00001   Gould,  Pat  Reed,  Richard 


00002   Bould,  Pat 


Reed,  Richard 


Uhole  Life 

FPfi 


.  do  design2a 

Enter  CI  lent ' s  Name  (Last, 

00001  Oxford,  Dan 

00002  Oxford,  Dan 

00003  Oxford,  Dan 


First )  i Ox ford,  Dan 
Doe,  Ronald 

Thompson,  Sharon 

Doe,  Ronald 


10  Pay  Term 
Putnam  High  Vield 
Vista 


.  do  design2a 

Enter  Client's  Name  (Last,  First)  iSeeker,  Jan 

00001   Seeker,  Jan  Thompson,  Sharon 


Single  Premium  Li  fe 


SOLES  TOTALS  BY  PRODUCT  TYPE 


*  TOTAL  FOR  PRODUCT  TYPEl  ANN 

FPA 

**  SUBTOTAL  ** 


2000.  00 
2000. 00 


*  TOTAL  FOR  PRODUCT  TYPE:  INS 
Whole  Life  20000.00 

10  Year  Paid  Life  50000.00 

##  SUBTOTAL  ** 


#  TOTAL  FOR  PRODUCT  TYPE*  IRA 
Fidel ity  Overseas 
»#  SUBTOTAL  ** 


##  TOTAL  ** 


10000.00 
10000.00 


FIGURE  5.2.3 
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DESIGN  3 

PROGRAM  1 
set  talh  off 

accept  "Enter  Client's  Name  (Last,  First)  "  to  clnt 
use  policy 

copy  to  tempi  field  name, agent , type, plan  for  name-clnt 
use  tempi 
list 


PROGRAM  2 

set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  ■  to  start idate 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  endtdate 

accept  "Enter  agent's  name  (Last,  First)  -    to  agentid 

use  policy 

copy  to  tempi  for  agent  -  agentid) 

.and.  val (datessold)  >-  startidate; 

•and.  val (dateisold)  (=  end:date 
use  tempi 

sort  on  type  to  temp2 
use  temp3 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.3.1 
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DESIGN  3 
REPORT  FORM    SRLESRGT 


ENTER  OPTIONS,  M-LEFT  MBRGIN,  L=LINES/PBGE,  W=PBGE  WIDTH 

PAGE  HEADING?  (Y/N>  y 

ENTER  PAGE  HEADING!  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REOUIRED?  <Y/N)  y 

SUBTOTALS  IN  REPORT?  <Y/N)  y 

ENTER  SUBTOTALS  FIELDl  typ» 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  <Y/N)  n 

ENTER  SUBTOTAL  HEADING!  TOTAL  FOR  PRODUCT  TYPEl 

COL      U I DTH, CONTENTS 

001      SO, plan 

ENTER  HEADING I  PLAN 

OOS      S, amt lof t ins 

ENTER  HEADING  I  AMOUNT 

ARE  TOTALS  REOUIRED?  (Y/N)  y 


FIGURE  5.3.2 
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.  do  design3a 

Enter  Client**  Name  (Last, 

00001  Gould,  Pat 

00002  Gould,  Pat 


DESIGN  3 
PROGRAM  EHECUTIONS 


First )  iGould,  Pat 
Reed,  Richard 


Reed,  Richard 


LIFE  Whole  Life 
ANN   FPA 


.  do  design3a 
Enter  Client's  Name 

00001  Oxford,  Dan 

00002  Oxford,  Dan 

00003  Oxford,  Dan 


First)  rOxford,  Dan 
Doe,  Ronald 


Doe,  Ronald 
Thompson,  Sharon 


IRA   Vista 

LIFE  10  Pay  Term 

IRA   Putnam  High  Yield  Tru 


.  do  design3a 

Enter  Client's  Name  (Last,  First)  iSeeker,  Jan 

00001   Seeker,  Jan  Thompson,  Sharon 


LIFE  Single  Premium  Life 


SOLES  TOTALS  BY  PRODUCT  TYPE 


*  TOTAL  FOR  PRODUCT  TYPEr   ANN 
FPR  2000 

**  SUBTOTAL  #* 


*  TOTAL  FOR  PRODUCT  TYPEl   IRA 
Fidelity  Overseas  10000 

**  SUBTOTAL  ** 

1000O 


»  TOTAL  FOR  PRODUCT  TYPE i   LIFE 
Whole  Life  20000 

10  Year  Paid  Life         50000 
*#  SUBTOTAL  »» 

70000 

**    TOTAL    *# 


FIGURE    5.3.3 
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DESIGN  4 


PROGRAM  1 
set  talk  off 

accept  "Enter  Client's  Name  (Last,  First)  "  to  clnt 
use  proctown 

copy  to  tempi  field  ctname, prodtype, compprov  for  ctname-clnt 
use  tempi 
select  secondary 
use  agtcts 
select  primary 
join  to  newfile  for  ctname  -  s. ctnamei 

field  prodtype, compprov, agnname 
use  newfile 
list 


PROGRAM  2 

set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  "  to  start tdate 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  endidate 

accept  "Enter  agent's  name  (Last,  First)  "  to  agentid 

use  agtcts 

copy  to  tempi  field  ctname  for  agnname  ■  agentid 

use  tempi 

select  secondary 

use  proctown 

select  primary 

join  to  newfile  for  ctname  ■  s. ctnamei 

field  prodtype, compprov, issudate, amount 
use  newfile 
copy  to  tempS  for  issudate  >■  start  :date; 

.and.  issudate  <=■  endidate 
use  tempS 

sort  on  prodtype  to  temp3 
use  temp3 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.4.1 


54 


DESIGN  4 
REPORT  FORM    SRLESRGT 


ENTER  OPTIONS,  M=LEFT  MARGIN,  L-LINES/PAGE,  W-PAGE  WIDTH 

PAGE  HEADING?  (Y/N)  y 

ENTER  PAGE  HEADINGl  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REQUIRED?  (Y/N)  y 

SUBTOTALS  IN  REPORT?  (Y/N)  y 

ENTER  SUBTOTALS  FIELDi  prodtyp* 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADING]  TOTAL  FOR  PRODUCT  TYPEl 

COL      WIDTH, CONTENTS 

001  20, compprov 
ENTER  HEADINGl  PLAN 

002  10, amount 
ENTER  HEADINGl  AMOUNT 

ARE  TOTALS  REQUIRED?  (Y/N)  y 


FIGURE  5.4.2 
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DESIGN  4 
PROGRRM  EXECUTIONS 


.  do  designAa 

Enter  CI ient'  s  Name  (La 

00001  LIFE  Whole  Life 

00002  ANN   FPA 


First)  iGould,  Pat 
Reed,  Richard 
Reed,  Richard 


.  do  design4a 

Enter  Client's  Name  (Last,  First)  lOxford,  Dan 

00001  IRA   Vista  Doe,  Ronald 

00002  LIFE  10  Pay  Term  Doe,  Ronald 

00003  IRA   Putnam  High  Yield     Doe,  Ronald 


,  do  design4a 

Enter  Client's  Name  (Last,  First)  iSeeker,  Jan 

00001   LIFE  Single  Premium  Life   Thompson,  Sharon 


PLAN 


SALES  TOTALS  BY  PRODUCT  TYPE 


AMOUNT 


*  TOTAL  FOR  PRODUCT  TYPEi   ANN 
FPA  2000 

•*  SUBTOTAL  *# 

£000 


»  TOTAL  FOR  PRODUCT  TYPE  I   IRA 
Fidelity  Overseas  10000 

**  SUBTOTAL  *# 

10000 


#  TOTAL  FOR  PRODUCT 

TYPE: 

LIFE 

10  Year  Paid  Life 

50000 

Whole  Life 

20000 

*#    SUBTOTAL  ** 

70000 

**    TOTAL    »# 


FIGURE    5.4.3 
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DESIGN  5 


PROGRAM    1 

set    talk    off 

accept    "Enter    Client's    Name    (Last,     First)     "    to   clnt 

use    agent 

copy  to  tempi  field  agtname  for  agtcname-clnt 

use  tempi 

list 

use  client 

copy  to  tempa  field  cltpolno  for  cltname=clnt 

use  temp2 

select  secondary 

use  policy 

join  to  newfile  for  cltpolno  ■  s. polnoi 

field  poltype, polplan 
use  newfile 
list 


PROGRAM  2 

set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  "  to  start :date 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  endidate 

accept  "Enter  aQent'B  name  (Last,  First)  "  to  agentid 

use  pol icy 

copy  to  tempi  field  polno, poltype, polplan,  polamont  fori 

poldate  >-  startrdate  .and.  poldate  <=  endidate 
use  agent 

copy  to  temp2  field  agtcname  for  agtname  »  agentid 
use  client 
select  secondary 
use  tempS 
select  primary 
join  to  newfile  for  cltname  -  3. agtcname) 

field  cltpolno 
use  newfile 
select  secondary 
use  tempi 
select  primary 
join  to  final  for  cltpolno  ■  s. polno; 

field  poltype, polplan, polamont 
use  final 

sort  on  poltype  to  finalsort 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.5.1 


67 


DESIGN  5 
REPORT  FORM    SRLESRGT 


ENTER  OPTIONS,  M-LEFT  MARGIN,  L-LINES/PBGE,  W-PAGE  WIDTH 

PAGE  HEADING?  <V/N)  y 

ENTER  PAGE  HEADINGi  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REQUIRED?  (Y/N)  y 

SUBTOTALS  IN  REPORT?  (Y/N)  y 

ENTER  SUBTOTALS  FIELD  I  poltype 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADINGi  TOTAL  FOR  PRODUCT  TYPEl 

COL      WIDTH, CONTENTS 

001  £5, polplan 
ENTER  HEADINGI  PLAN 

002  10,  polamont 
ENTER  HEADINGi  AMOUNT 

ARE  TOTALS  REQUIRED?  (Y/N)  y 


FIGURE  5.5.2 
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DESIGN  5 
PROGRAM  EXECUTIONS 


.  do  designSa 

Enter  Client's  Name  (Last,  First)  iGould,  Pat 

00001   Reed,  Richard 

00001  LIFE  Whole  Life 

00002  ANN   FPA 


.  do  designSa 

Enter  Client's  Name  (Last,  First)  (Oxford, 

00001   Doe,  Ronald 

00001  IRA   Vista 

00002  LIFE  10  Pay  Term 

00003  IRA   Putnam  High  Yield 


.  do  designSa 

Enter  Client's  Name  (Last,  First)  iSe 

00001   Thompson,  Sharon 

00001   LIFE  Single  Premium  Life 


SALES  TOTALS  BY  PRODUCT  TYPE 


«  TOTAL  FOR  PRODUCT  TYPE  I   IRP 
Fidelity  Overseas  10000 

♦♦  SUBTOTAL  «• 


»  TOTAL  FOR  PRODUCT  TYPE:   LIFE 

10  Year  Paid  Life  50000 

Whole  Life  £0000 
««  SUBTOTAL  »* 


*  TOTAL  FOR  PRODUCT  TYPE:   ANN 

FPA  2000 

»«  SUBTOTAL  »♦ 

2000 


TOTAL  «» 


FIGURE  5.5.3 
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DESIGN  6 


PROGRAM     1 

set    talk    off 

accept    "Enter   Client's    Name    (Last,    First)     "    to    clnt 

use   client 

copy  to  tempi  field  ename  for  client-clnt 

use  tempi 

list 

use  policy 

copy  to  temp£  field  prodtype, product  for  client=clnt 

use  temp£ 

list 


set  talk  off 

input  "Enter  starting  date  for  sales  totals  (YYMMDD)  "  to  start idats 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  endidate 

accept  "Enter  agent's  name  (Last,  First)  "  to  agentid     , 

use  client 

copy  to  tempi  field  client  for  ename  -  agentid 

use  tempi 

select  secondary 

use  policy 

select  primary 

join  to  newfile  for  client  -  s.clienti 

field  prodtype,  product, date i sold, faceiamt 
use  newfile 

copy  to  temp£  for  date:sold  )■  start :date| 
.and.  dateisold  <-  end (date 
use  tempS 

sort  on  prodt y pe  to  t emp3 
use  temp3 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.6.1 
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DESIGN  6 
REPORT  FORM    SRLESR6T 


ENTER  OPTIONS,  M-LEFT  MARGIN,  L-LINES/PflGE,  W=PAGE  WIDTH 

PAGE  HEBDING?  (Y/N)  y 

ENTER  PBGE  HEADING:  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  (Y/N)  n 

ARE  TOTALS  REQUIRED?  (Y/N)  y 

SUBTOTALS  IN  REPORT?  (Y/N)  y 

ENTER  SUBTOTALS  FIELDl  prodtyps 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADINGi  TOTAL  FOR  PRODUCT  TYPE  I 

COL      WIDTH, CONTENTS 

001  30, product 
ENTER  HEADINGi  PRODUCT 

002  10, facetamt 
ENTER  HEADING!  AMOUNT 

ARE  TOTALS  REQUIRED?  <Y/N>  y 


FIGURE  5.6.2 
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DESIGN  6 
PROGRAM  EHECUTIONS 


.  do  deslgn6a 

Enter  Client's  Name  (Last,  First)  iGould,  Pat 

00001   Reed,  Richard 

00001  LIFE  Whole  Life 

00002  BNN   FPA 


.  do  design&a 

Enter  Client's  Name  (Last,  First)  lOxford,  Dan 

00001   Doe,  Ronald 

00001  IRA   Vista 

00002  LIFE  10  Pay  Term 

00003  IRA   Putnam  High  Yield 


.  do  design6a 

Enter  Client's  Name  <Last,  First)  iSeeker,  Jan 

00001   Thompson,  Sharon 

00001   LIFE  Single  Premium  Life 


SOLES  TOTALS  BY  PRODUCT  TYPE 


PRODUCT  AMOUNT 

»  TOTAL  FOR  PRODUCT  TYPE:  BNN 
FPA  2000.  OO 

#«  SUBTOTAL  »* 

2000.  00 


»  TOTAL  FOR  PRODUCT  TYPEs  IRP. 
Fidelity  Overseas       10000.00 
»»  SUBTOTAL  »* 

10000. 00 


♦  TOTAL  FOR  PRODUCT  TYPES  LIFE 
10  Year  Paid  Life       50000.00 
Whole  Life  20000.00 

«»  SUBTOTAL  ♦• 

70000. 00 

♦#    TOTAL    *» 

82000. 00 


FIGURE    5.6.3 
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DESIGN  7 


set    talk    off 

accept  "Enter  CI lent '  s  Name  (Last,  First )  "  to  clnt 

use  cl ient_p 

copy  to  tempi  field  c 1  name, se 1  name, pname  for  clname 

use  tempi 

list 


PROGRAM  2 

set  talk  off 

input  "Enter  starting  date  for  sales  totals  <YYMMDD)  "  to  start idata 

input  "Enter  ending  date  for  sales  totals  (YYMMDD)  "  to  end  tdate 

accept  "Enter  agent' s  name  (Last ,  First  >  "to  agent  id 

use  cl ient_p 

copy  to  tempi  for  selname  ■  agent  id j 

.and.  val(dateiss)  >—    startidate; 

.  and.  val  (dateiss)  <«=  end  idate 
use  tempi 

sort  on  ptype  to  tempS 
use  tempS 
set  eject  off 

report  form  salesagt  to  print  plain 
set  print  off 


FIGURE  5.7.1 
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DESIGN  7 
REPORT  FORM    SRLESRGT 


ENTER  OPTIONS,  M-LEFT  MARGIN,  L-LINES/PAGE,  U=PAGE  UIDTH 

PBGE  HEADING?  <Y/N)  y 

ENTER  PBGE  HEBDINGl  SALES  TOTALS  BY  PRODUCT  TYPE 

DOUBLE  SPACE  REPORT?  <Y/N)  n 

BRE  TOTALS  REQUIRED?  (Y/N)  y 

SUBTOTALS  IN  REPORT?  (Y/N)  y 

ENTER  SUBTOTALS  FIELD  I  ptype 

SUMMARY  REPORT  ONLY?  (Y/N)  n 

EJECT  PAGE  AFTER  SUBTOTALS?  (Y/N)  n 

ENTER  SUBTOTAL  HEADING!  TOTAL  FOR  PRODUCT  TYPEl 

COL      UIDTH, CONTENTS 

001      30, pname 

ENTER  HEADING!  PLAN 

OOS      10, pamt 

ENTER  HEADING!  AMOUNT 

ARE  TOTALS  REQUIRED?  (Y/N)  y 


FIGURE  5.7.2 
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DESIGN? 
PROGRRM  EXECUTIONS 


.  do  design7a 
Enter  Client's  Name 

00001  Gould,  Pat 

00002  Gould,  Pat 


(Last,  First)  i Gould, 
Reed,  Richard 
Reed,  Richard 


Whole 
FPA 


.  do  design7a 

Enter  CI ient' s  Name 

00001   Oxford,  Dan 

O000£   Oxford,  Dan 

00003   Oxford,  Dan 


<Last,  First)  lOxford, 
Doe,  Ronald 
Doe,  Ronald 
Thompson,  Sharon 


Vista 

10  Pay  Term 

Putnam  High  Yield  Tru 


.  do  desi  gn7a 
Enter  CI ient'  » 
00001   Seeker, 


Name  (Las 


t.  First )  iSeeker, 
Thompson,  Sharon 


Single  Premium  Life 


SALES  TOTALS  BY  PRODUCT  TYPE 


*  TOTAL  FOR  PRODUCT  TYPEi 

FPA 

#*  SUBTOTAL  ## 


£000. 00 
£000. 00 


*  TOTAL  FOR  PRODUCT  TYPEi 
Fidelity  Overseas 
**  SUBTOTAL  ** 


10000.00 
10000.  00 


#  TOTAL  FOR  PRODUCT  TYPE: 

Whole  Life 

10  Year  Paid  Life 

*»  SUBTOTAL  ** 


##  TOTAL  ** 


£0000. 00 
50000. 00 


70000. OO 


FIGURE    5.7.3 
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EHECDTION  TIME 

DESIGN 


LINES  OF  CODE 

APPLICATION 

Online 

Batch 

Online  Trials 

Botch 

R 

B 

C 

10.52 

19.47 

19.49 

14.77 

21 

15 

10.70 

19.35 

19.36 

14.99 

18.72 

19.51 

18.84 

13.94 

Hug. 

18.66 

19.44 

19.23 

14.57 

8.37 

8.64 

8.63 

21.57 

6 

12 

8.35 

8.56 

8.34 

22.57 

8.43 

8.61 

8.31 

22.53 

flug. 

8.38 

8.60 

8.43 

22.22 

7.72 

7.10 

7.88 

20.03 

6 

12 

7.56 

7.29 

7.73 

20.07 

7.68 

7.20 

7.83 

19.64 

Hug- 

7.65 

7.20 

7.81 

19.91 

9.63 

9.59 

9.87 

26.11 

11 

19 

18.51 

9.59 

9.53 

25.69 

10.05 

9.14 

9.61 

25.86 

Hug. 

10.06 

9.44 

9.67 

25.89 

13.61 

13.70 

13.25 

26.77 

14 

23 

13.52 

13.03 

13.59 

25.22 

13.70 

13.73 

13.30 

25.08 

«ug. 

13.64 

13.75 

13.30 

25.69 

7.02 

7.65 

7.52 

26.86 

10 

19 

7.52 

7.55 

7.67 

27.10 

7.70 

7.54 

7.63 

26.54 

i»9- 

7.60 

7.58 

7.54 

26.83 

4.26 

4.35 

4.32 

15.65 

6 

12 

4.30 

4.31 

4.32 

16.23 

4.23 

4.31 

4.36 

15.84 

Rug- 

4.29 

4.32 

4.33 

15.91 

FIGORE  5.8 
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CHAPTER  6:   Conclusions 

When  designing  a  database,  much  consideration  should  be  giuen  to 
the  particular  enuironment  it  mill  most  widely  be  used  in.  fls  shown  by 
the  results  in  the  preuious  chapters,  programs  enecuted  in  an 
interactiue  enuironment  tend  to  run  as  effeciently  as  the  data  can  be 
accessed.  See  figure  6.1  for  comparison  graphs  plotting  the  designs 
against  execution  time  and  lines  of  code  used  in  the  application 
programs.  Figure  6.2  contains  the  same  information  as  figure  6.1  but  in 
design  order  so  it  is  easier  to  moke  comparisons  between  execution 
time  and  the  number  of  coding  lines  used  for  each  design. 

The  more  file  accesses  one  has,  generally  speaking,  the  greater  the 
oueroll  run  times  will  become.  If  it  is  known  that  a  database  will  be 
most  widely  used  in  on  on-line  enuironment  close  attention  should  be 
made  to  group  the  data  most  often  accessed  into  as  few  of  files  as 
possible  and  still  maintain  a  schema  that  is  easily  understood.  This 
helps  in  reducing  the  redundant  data,  fln  euen  greater  benefit  is  that 
the  number  of  lines  of  code  used  in  implementation  can  be  reduced 
significantly.  With  the  cost  of  softwore  deuelopment  at  what  it  is 
today,  it  brings  a  monetary  significonce  into  the  picture  as  well. 

In  batch  processing,  by  its  nature,  one  is  not  too  concerned  with 
immediate  response  times  when  running  reports.  More  attention 
should  be  giuen  to  hauing  all  the  data  auailable  to  run  any  required 
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reports.  This  puts  a  great  deal  of  responsibility  on  the  systems  analyst 
during  the  deuelopment  phase  of  a  database  design  project.  It  Is 
important  to  know  what  the  user  wants  when  it  comes  to  the  types  of 
reports  that  are  required.  R  missing  attribute  in  an  entity  can  cause 
certain  information  to  not  be  auailable  as  was  the  case  in  seueral  of  the 
schemes  used  in  this  project.  Modification  to  the  database  would  then 
be  required. 

Future  work  that  could  be  done  relating  to  this  project  would  be  to 
use  a  different  database  management  system.  DBASE  II  is  a  powerful 
database,  but  one  of  the  limitations  of  dBRSE  II  is  that  it  can  not  haue 
more  than  two  files  open  at  a  time.  There  are  more  user  friendly 
databases  on  the  market,  such  as  dBRSE  III  and  III+,  which  haue 
greater  report  generating  capabilities. 

More  application  programs  could  be  deueloped  to  see  whether  the 
trends  discussed  In  the  preulous  chapters  consistently  hold  true.  Larger 
files  could  also  be  used  to  tell  whether  execution  time  patterns  are 
affected  proportionally. 

In  summary,  the  way  a  database  system  is  designed,  weighs 
heauily  on  the  type  of  environment  it  is  going  to  be  used  in.  It  is  up  to 
the  systems  analyst  to  make  these  distinctions  so  a  system  can  be 
designed  to  process  data  as  effeclently  as  possible. 
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ABSTRACT 

Dery  little  information  can  be  found  in  the  literature  comparing 
different  schema*  using  the  same  application  enuironment.  In  this 
paper,  comparison  of  seven  different  schemas  is  made  using  dBflSE  II  as 
the  database  management  system. 

Two  application  programming  problems  simulating  online  and  batch 
characteristics,  were  implemented  on  each  of  the  seuen  schemas  and 
comparison  was  made  on  the  basis  of  the  number  of  lines  of  codes  used 
to  write  the  programs  and  the  execution  time  of  each.  From  these 
determinations,  some  guidance  is  provided  to  database  designers  to 
predict  the  type  of  schema  needed  to  meet  a  particular  kind  of 
application  programming  need. 


